DB 구조(ER Diagram) 정보
DB 구조(ER Diagram)
본문
대부분의 프레임워크에서는 ORM(Object Relationship Management)을 사용합니다.
처음 접했던 것이 라라벨 공부하면 Eloquent 라는 ORM 이었습니다.
belongs to, has one, has many, has many through, has one through, has and belongs to many
와 같은 Relationship을 통해서 데이타베이스를 쉽게 억세스합니다.
https://sir.kr/so_app/401 처음 봤을 때에는 루비 온 레일스쪽부터 나온것 같습니다.
이런 ERDiagram을 작성하는 곳도 많이 있지만,
https://www.erdcloud.com/ 에 그누보드/영카트, Ciboard등이 올라가 있습니다. (나리야는 안보이네요.)
이번에 사용하는 곳은 https://mermaid-js.github.io/mermaid-live-editor 여기입니다.
텍스트로 간단하게 입력하면 나옵니다.
그래서 그누보드의 릴레이션쉽을 대략적으로 만들어 봤습니다.(실제연결은 안된 곳도 있습니다.)
Value (left) | Value (right) | Meaning |
---|---|---|
|o |
o| |
Zero or one |
|| |
|| |
Exactly one |
}o |
o{ |
Zero or more (no upper limit) |
}| |
|{ |
One or more (no upper limit) |
has many: Member has many Point
Point has one Member 의 관계가 된다고 하면 (맞나요?)
그러면 Member ||--|{ Point 가 될 것 같네요. 이해가 되시나요..
---
erDiagram
Member ||--o{ Scrap : "스크랩"
Member ||--o{ Login : "로그인 정보"
Member ||--o{ Autosave : "임시 저장"
Member ||--o{ Write_free : "글과 댓글"
Member ||--o{ Board_good : ""
Member ||--o{ Point : ""
Board ||--|{ Write_free : ""
Board ||--|{ Bo : "여분필드"
Group ||--|{ Board : ""
Write_free ||--o{ Scrap : "스크랩"
Write_free ||--o{ Board_file : "첨부파일"
Write_free ||--o{ Board_good : "추천/비추천"
---
멤버나 글에 필요한 여분필드도 릴레이션쉽으로 연결해 보면 어떨까 해서 정리해 봤습니다.
그누보드는 DB에 이런 관계성 연결이 많이 떨어져 있고, 한 테이블에 다 들어가 있다보니,( 그래서 속도가 빠른가요?)
참조하기엔 조금 어려운 것 같습니다. 그래서 Ciboard의 DB구조도 많이 참조합니다.
영카트부분은 많이 연결되어 있는 것으로 보입니다.
|| -- o{ 형태로.
0
댓글 6개

그럼 장점이,
한 학생의 역대 수강이력을 보는 것에 잇점이 있고, 가장 인기많은 강의를 볼 수 있고...
대신 조인으로 인한 서버의 버벅거림 추가될 수 있으니 조인할 때 인덱스를 잘 타도록 조인을 잘 해야한다는... ^^;
흠... 다 아시는 사실을 이야기했네요. 혹여나 보시는 분들 중에 필요하실까 하여... 숟가락을 올렸습니다.

즉 many to many 관계는 중간 테이블을 두고 서로 one to many의 관계를 가진다고 까지가 제가 알고 있는 지식입니다. (틀릴수도. ㅎㅎ)
필요한 기능(필드)가 정해 지면, 기본(필수) 필드만으로 Database를 만들고 Document가 아닌 실제 erd(sql을 import)를 erdcloud에 올려 볼려고합니다.
많은 분들이 조금씩 필요기능, 검증만 해주면, 나중에 실수등을 줄일 수 있을 것 같긴한데...
그래도 열심히 해봐야죠.


모던js를 최근 좀 관심을 가지고 보고 있는데, 혹시 디비를 nosql(몽고, 파이어베이스등...) 로 갈 수 있는 가능성도 열어둬야할 것 같습니다. 데이터를 처리하기 위한 graphql도 최근 인기가 많아지는 것 같던데... 그럼 조인이나 속도문제는 해결이 되지 않을지 모르겠습니다.
하지만, 예전에는 (아니 지금도) 레가시 한 방법으로는 조인이나 인덱스 이런 것이 엄청 중요 했는데, 최근에는 많이 무시하고 바로 DB에서 json 으로 원하는 결과를 받아와버리는 방법을 많이 쓰는 것 같아요.
jquery 의 비중이 여전히 충분하지만, 그래도 점점 개발자들이 손을 떼고 있다는데... 워낙 편하다보니 기본(vanila) js ES5,6등에도 너무 그동안 무심해왔던 것 같아요.
촛점없는 얘기 죄송합니다. 제가 워낙 산만해서... ㅜㅜ;a

지금까지 여러가지 고민을 해 왔던 것이 기존 보드와의 호환때문이었는데, 제 실력으로는 도저히 안되네요. 그래서 최신 트렌드에 맞게 DB First부터 시작하고, REST가 되면,
그 다음은 당연히 GRAPHQL까지 고려하고 있습니다.
최신 트렌드중 1-2년후에 잘 나갈 만한것을 골라서 미리 미리해야 된다고 봅니다.
그래서 Angular, React, Vue등과 Typescript등으로 Frontend가 될 수 있게 하고 싶습니다.
https://github.com/gothinkster/realworld 여기에서 하나 고를 수 있는 한국형이 되기를..