|
|
|
Таблицы с отношениями один-к-одному
|
|||
|---|---|---|---|
|
#18+
Здравствуйте, Предположим несколько сущностей: 1) Аккаунт пользователя (данные для идентификации - логин/пароль/e-mail) 2) Баланс пользователя 3) Профайл пользователя (Персональные данные - имя/фамилия/отчество/телефон/пол и т.п.) Одному пользователю может соответствовать один баланс и один профайл. Как лучше сделать? 1) Сделать три таблицы: accounts, statements, profiles, при этом в таблицах statements и profiles внешние ключи, которые ссылаются на первичный ключ (account_id) в таблице с аккаунтами. 2) Те же три таблицы, но в этом случае в таблице accounts будут внешние ключи которые ссылаются на первичные ключи в таблицах profiles и statements (т.е. в таблице accounts будут поля (account_id, profile_id, statement_id, login, password...)) 3) Не мучиться с отношениями, и сделать одну таблицу в которой будут все эти данные, т.к. все-равно одному аккаунту соответствует только один баланс и профайл (т.е. сделать все поля свойствами аккаунта а не разделять на три сущности). Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2010, 14:24 |
|
||
|
Таблицы с отношениями один-к-одному
|
|||
|---|---|---|---|
|
#18+
а при каких-либо условиях свойства и требования к этим таблицам могут различаться? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2010, 14:26 |
|
||
|
Таблицы с отношениями один-к-одному
|
|||
|---|---|---|---|
|
#18+
Если я правильно понял ваш вопрос, то - нет. Тип пользователей только один - физические лица, соответственно набор полей в профайле одинаковый для всех, и если будет меняться то для всех сразу. Что касается балансов - аналогично. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2010, 14:29 |
|
||
|
Таблицы с отношениями один-к-одному
|
|||
|---|---|---|---|
|
#18+
Речь не про категории записей в таблицах, а про сами таблицы. Например, потребуются ли различные настройки прав на чтение разных таблиц разными пользователями? Или понадобится ли реплицировать одну из таблиц при запрете реплицировать другую? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2010, 14:32 |
|
||
|
Таблицы с отношениями один-к-одному
|
|||
|---|---|---|---|
|
#18+
miksoftРечь не про категории записей в таблицах, а про сами таблицы. Например, потребуются ли различные настройки прав на чтение разных таблиц разными пользователями? Или понадобится ли реплицировать одну из таблиц при запрете реплицировать другую? В обоих случаях - нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2010, 14:35 |
|
||
|
Таблицы с отношениями один-к-одному
|
|||
|---|---|---|---|
|
#18+
avb19873) Не мучиться с отношениями, и сделать одну таблицу в которой будут все эти данные, т.к. все-равно одному аккаунту соответствует только один баланс и профайл (т.е. сделать все поля свойствами аккаунта а не разделять на три сущности). Предлагаю этот вариант, ибо это есть одна сущность - пользователь. ID NAME SEX PHONE LOGIN PASS E_MAIL BALANCE1 avb1987 M 12345 avb1987 qwerty avb1987@avb1987.ru 12345 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2010, 19:06 |
|
||
|
Таблицы с отношениями один-к-одному
|
|||
|---|---|---|---|
|
#18+
avb1987Здравствуйте, Предположим несколько сущностей: ... Вообще говоря первые два варинта не отражают модель данных, потому что в какие то моменты времени у вас неизбежно будут отсутствовать один или два обязательных объекта. Обойти это можно отложенной проверкой ограничений целостности, или вообще их не создавать, что не есть good. Если не предполагается дальнейшее усложнение системы (например совместное пользвание одного Л/С - типа семейный тариф), то проще всего свалить все сущности в одну таблицу. 2, A1ek5andr0. В исходной модели сущности "Пользователь" нет. В противном случае и вопроса бы не возникло. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2010, 15:56 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=74&tid=1542703]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
95ms |
get topic data: |
13ms |
get forum data: |
4ms |
get page messages: |
53ms |
get tp. blocked users: |
2ms |
| others: | 215ms |
| total: | 412ms |

| 0 / 0 |
