Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Форумы портала PHP.SU :: Версия для печати :: Организация структуры.
Форумы портала PHP.SU » » Вопросы новичков » Организация структуры.

Страниц (1): [1]
 

1. jonston - 07 Сентября, 2017 - 11:16:23 - перейти к сообщению
Добрый день!Есть модуль пользователя (таблица users) и резюме (таблица resume) отношение один к одному.С точки зрения архитектуры лучше сделать $user->getResume($user_id) или $resume->getByUserId($user_id).Ключ user_id храниться в таблице resume
2. Sail - 09 Сентября, 2017 - 00:46:31 - перейти к сообщению
jonston пишет:
Добрый день!Есть модуль пользователя (таблица users) и резюме (таблица resume) отношение один к одному.С точки зрения архитектуры лучше сделать $user->getResume($user_id) или $resume->getByUserId($user_id).Ключ user_id храниться в таблице resume

Оба варианта.
К тому-же, с точки зрения предметной области актуальна связь один (user) ко многим (резюме)... Соискатель может быть заинтересован в том, чтобы для разных видов деятельности составлять отличающиеся друг от друга резюме...
(Добавление)
Соответственно, если 1:n - то в первом случае метод возвращает коллекцию (множество)...
3. LIME - 09 Сентября, 2017 - 04:37:40 - перейти к сообщению
jonston если исключить аргументы уважаемого оратора выше то вопрос.
а нахрена создавать 1к1?
пихай все в одну таблицу
однако выше уже сказали что резюме может быть более чем 1
я вообще...за жизнь...что тебя сподвигло создавать 1к1? я знаю когда это это бывает нужно...это вертикальное шардирование...а тебе оно надо?
короче чтоб не быть пустозвоном поясню-
если некоторые поля часто обновляются то их выносят отдельно в 1к1 чтоб не ломать кэш и не писать лишнего в диск
но это оптимизация
тебе оно зачем?
(Добавление)
jonston а насчет юзера это вообще отдельная тема
например поле last_active вообще стоит вынести за субд
если интересно могу порасскозать интересного
(Добавление)
jonston а по сабжу оба метода норм
оба могут быть
никто не запрещает делать как удобнее
4. jonston - 10 Сентября, 2017 - 02:30:01 - перейти к сообщению
LIME пишет:
jonston
а нахрена создавать 1к1?

Резюме это сущность.У него есть собственные поля.Как нахрена?У резюме есть свои связи.Ссылки на сайты например.Это не говоря о одинаковых именах если говорить в общем об отношениях 1:1.
(Добавление)
Sail пишет:

Оба варианта.
К тому-же, с точки зрения предметной области актуальна связь один (user) ко многим (резюме)... Соискатель может быть заинтересован в том, чтобы для разных видов деятельности составлять отличающиеся друг от друга резюме...

Допустим в дальнейшем будет возможность добавлять несколько резюме.Вопрос в том как правильно обращаться из родителя к потомку или из потомка к родителю.В общем я понял что оба метода равноправны.
5. LIME - 10 Сентября, 2017 - 17:33:16 - перейти к сообщению
я к тому что проще объединить 1к1 в одну таблицу
вертикально разделять полезно только если одни поля часто переписываются а другие редко
иначе вообще нет смысла делать отдельные таблицы
6. jonston - 10 Сентября, 2017 - 19:13:09 - перейти к сообщению
LIME пишет:
я к тому что проще объединить 1к1 в одну таблицу
вертикально разделять полезно только если одни поля часто переписываются а другие редко
иначе вообще нет смысла делать отдельные таблицы


Как реализовать связи тогда с резюме?
7. LIME - 11 Сентября, 2017 - 11:08:13 - перейти к сообщению
никак
перенеси поля резюме в юзера и все
избавишься от лишнего джоина
если озаешь ORM можешь даже сделать разные модели для одной таблицы

 

Powered by ExBB FM 1.0 RC1