|
| |
|
|
| |
для: Zilog
(02.05.2011 в 13:23)
| | | Практически нет... вернее можно через информационную схему исхитриться такое построить, но запрос будет мягко говоря многоэтажным.
PS Под новые вопросы лучше заводить новые темы. | |
| |
|
|
| |
|
|
| |
для: cheops
(02.05.2011 в 10:52)
| | | Спасибо. А можно ли (допускает ли это Mysql) в запросе JOIN'ить ту или иную таблицу в зависимости от состояния какого-то поля? | |
| |
|
|
| |
|
|
| |
для: Zilog
(02.05.2011 в 02:35)
| | | Да, разные данные, лучше вынести в отдельные таблицы, а в перевой таблице хранить общие данные вроде логинов, паролей, e-mail | |
| |
|
|
| |
|
|
| | Задача — создать сервис оформления заявок для юр. или физ. лиц.
Вроде всё просто: заказ должен знать хранить id заказчика (клиента).
Однако, клиенты имеют разный набор данных, если для физ лица это фио, паспорт-шмаспорт, то для юр. лица это название компании, куча всяких реквизитов банковских и т.д.
Возник вопрос, как хранить данные клиентов? В одной БД, с кучей полей на все случаи жизни и юзать часть из них по ситуации, или же разделить? Если разделить, не усложинит ли это в дальнейшем жизнь?
--------
Склоняюсь к след. решению:
Таб.1
customerID
customerType - физ/юр
customderDataID - id на таблицу Тф или Тю с данными клиента. В дальнейшей работе, при необходимости вывести клиента к заказу, данные клиента выбираем из таблицы Тф или Тю в зависимости от состояния предыдущего поля. Соответственно, обработчик данных для каждого случая везде свой, т.к. разный набор данных, с разными именами полей. | |
| |
|
|
|
