|
|
|
Отношение многие ко многим в одной таблице!
|
|||
|---|---|---|---|
|
#18+
Добрый день. У меня возник такой вопрос - есть таблица групп TGroups в которой есть теже поля, что и в таблице TUsers. Но в таблице TUsers есть еще и другие поля, присущи только сущности Users. Эти две сущности (группы и пользователи) связаны между собой отношением многие ко многим. И на данный момент есть два способоа реализовать эту связь в базе данных - создать универсальную таблицу, в которой были бы поля группы и пользователя и добавить туда флажок isGroup. Также нужно будет добавить еще одну таблицу с двумя ключами UserId и GroupId, которая поможет реализовать связь многие ко многим. (dbschema1.jpg) И есть другой подход - создать три таблицы TUsers, TGroups и связующую TUsersToGroups. (dbschema2.jpg) Какой подход лучше? Есть ли отличия по производительности? Заранее благодарю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2008, 20:31 |
|
||
|
Отношение многие ко многим в одной таблице!
|
|||
|---|---|---|---|
|
#18+
Косогор Павел ... есть таблица групп TGroups в которой есть теже поля, что и в таблице TUsers... И какой смысл хранить в этих двух таблицах одну и ту же информацию? В "Users" - информация о пользователях, в "Groups" - код группы, код пользователя ( ну возможно еще какие-нибудь необходимые поля; например locked - это на тот случай если у вас появится желание заблокировать всю группу :) и т.д. ). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2008, 20:51 |
|
||
|
Отношение многие ко многим в одной таблице!
|
|||
|---|---|---|---|
|
#18+
К примеру удобно обрабатывать сущности User и Group как одну, используя только их общие поля, а когда понадобиться по флагу isGroup определить это пользователь, если да, то знач можно использовать остальные поля в таблице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2008, 21:00 |
|
||
|
Отношение многие ко многим в одной таблице!
|
|||
|---|---|---|---|
|
#18+
стандартным и более понятным считается второй способ. в первом будет выигрыш по скорости на групповых операциях, если это операции общие без построения именно связей. если надо будет строить связи и делать что-то в зависимости от попадания юзера в группу - выигрыша не будет. а вот худшая читабельность (и увеличение ошибок при реализации) - точно будут. во ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.06.2008, 14:09 |
|
||
|
Отношение многие ко многим в одной таблице!
|
|||
|---|---|---|---|
|
#18+
а что насчет экономии места на диске? какой случай лучше? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.06.2008, 14:41 |
|
||
|
Отношение многие ко многим в одной таблице!
|
|||
|---|---|---|---|
|
#18+
>> а что насчет экономии места на диске? какой случай лучше? Ты скажи сразу, сколько у тебя пользователей, и какой диск, а мы уж тут придумаем чего-нить... :-) Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.06.2008, 15:17 |
|
||
|
Отношение многие ко многим в одной таблице!
|
|||
|---|---|---|---|
|
#18+
Пользователей больше 100000, диск большой, но заказчики жмут место ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.06.2008, 16:36 |
|
||
|
Отношение многие ко многим в одной таблице!
|
|||
|---|---|---|---|
|
#18+
edges7 В "Users" - информация о пользователях, в "Groups" - код группы, код пользователя ( ну возможно еще какие-нибудь необходимые поля; например locked - это на тот случай если у вас появится желание заблокировать всю группу :) и т.д. ). Чего-то я здесь загнул. :) Короче, на ночь вредно давать советы. А то кошмары приснятся :) В "Users" - информация о пользователях, в "Groups" - информация о группах ( код группы, наименование группы и т.д. ). Также добавляем таблицу типа "User_Group" - код группы, код пользователя ( возможны и другие поля ). В общем все это похоже на ваш второй вариант. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.06.2008, 17:19 |
|
||
|
Отношение многие ко многим в одной таблице!
|
|||
|---|---|---|---|
|
#18+
Косогор Павела что насчет экономии места на диске? какой случай лучше? зависит от базы, но чисто интуитивно, второй вариант экономичнее за счет таблицы связей. дефрагментировать 3 таблицы легче, чем 1 большую. ...и сегментировать легче, если у вас количество юзеров зашкалит. но я думаю вы не в китае. :-) во ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.06.2008, 18:24 |
|
||
|
Отношение многие ко многим в одной таблице!
|
|||
|---|---|---|---|
|
#18+
Косогор ПавелПользователей больше 100000, диск большой, но заказчики жмут место ;) Кхм... а мне казалось, что этим обычно программисты занимаются.. :-) А если серьезно - едва ли на различиях вариантов реализации много места выиграется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.06.2008, 22:30 |
|
||
|
Отношение многие ко многим в одной таблице!
|
|||
|---|---|---|---|
|
#18+
могу рассказать, как на различиях реализации место теряется. если например сохранять в базу состояния разных обьектов в xml-формате. :-) "...а вдруг юзер захочет вернутся к своему процессу через 3 года?!.." растет как на дрожжжжжжжах! p.s. отклонился от темы. :-) во ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2008, 11:50 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=35372109&tid=1543818]: |
0ms |
get settings: |
7ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
165ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
32ms |
get tp. blocked users: |
1ms |
| others: | 206ms |
| total: | 434ms |
| 0 / 0 |
