|
|
|
Где держать данные?
|
|||
|---|---|---|---|
|
#18+
Есть таблица заказы. Потребовалось донолнительно вводить информацию о монтаже (кто смонтировал, когла смонтировал и т.д.) - монтазников может быть несколько. Вопрос эту информацию лучше добавлять в таблицу "заказы" (сделав дополнительные поля "Монтажник1", "Монтажник2", "Монтажник3", "ДатаМонтажа" и т.д.) или создать отдельную таьлицу? Какие будут плюсы/минусу того или другого варианта? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2007, 12:06 |
|
||
|
Где держать данные?
|
|||
|---|---|---|---|
|
#18+
ByKiSЕсть таблица заказы. Потребовалось донолнительно вводить информацию о монтаже (кто смонтировал, когла смонтировал и т.д.) - монтазников может быть несколько. Вопрос эту информацию лучше добавлять в таблицу "заказы" (сделав дополнительные поля "Монтажник1", "Монтажник2", "Монтажник3", "ДатаМонтажа" и т.д.) или создать отдельную таьлицу? Какие будут плюсы/минусу того или другого варианта? Однозначно: если стремишься следовать реляционному стандарту, то делать примерно такие таблицы Код: plaintext 1. 2. 3. 4. Плюсы: любое количество монтажников (от 0 до бесконечности) без пересоздания таблицы "Заказы", возможность частичного закрытия заказа Минусы: дополнительное время (обычно незначительное) на выборку данных из связанных таблиц... У Вашего первоначального варианта плюсы: "все данные в одном месте", а минус: сложность масштабирования структуры (если монтажников будет 2, то одно поле - лишнее; если монтажников когда-то будет 4 или 5 /будет монтаж в два этапа и т.д., то потребуется менять структуру таблицы) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2007, 12:42 |
|
||
|
Где держать данные?
|
|||
|---|---|---|---|
|
#18+
"монтазников может быть несколько" сколько конкретно? Если сколько угодно, то тут же всплывёт ограничение на количество колонок в таблице и вопрос решится в пользу дополнительной таблицы. Монтажники выполняют однотипные работы, или каждый определённый вид работ в фиксированном технологическом процессе? Если последнее, то лучше говорить о работах и кто их исполнял, чем о монтажнике(n). Тогда, наверное, лучше будет отмечать выполнение работ непосредственно в записи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2007, 13:12 |
|
||
|
Где держать данные?
|
|||
|---|---|---|---|
|
#18+
В силу большой неконкретности задачи, остановлюсь на первом варианте (доп. таблица). Спасибо за помощь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2007, 13:17 |
|
||
|
Где держать данные?
|
|||
|---|---|---|---|
|
#18+
Конечно надо выбирать вариант с ипользованием промежуточной таблицы и исходя из ограничений предметной области в зависимости от типа работы задавать ограничения на кол-во монтажников,на их квалификацию и исходя из этих ограничений строить вводилку монтажников (причем выйдет очень эффектно-для каждого типа работ можно в зав-ти от кол-ва монтажников строить список их привязки к работе). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2007, 15:08 |
|
||
|
Где держать данные?
|
|||
|---|---|---|---|
|
#18+
Вот после двух месяцев непомерных трудов, ошибок и изучений нарисовалась такая схема базы... Очень хотелось бы услышать недостатки и замечания. Заранее благодарен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2007, 12:38 |
|
||
|
Где держать данные?
|
|||
|---|---|---|---|
|
#18+
Напрашивается отселить в отдельную таблицу ваши 12 параметров. Тогда их может быть хоть 1 хоть 101. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2007, 13:49 |
|
||
|
Где держать данные?
|
|||
|---|---|---|---|
|
#18+
Только это??? ;) Спасибо, ято нашли время. Только уточните что значит отселить? Ещё одна таблица с 12 полями? Или типа BlindIDAdditionalParameterNameAdditionalParametrValue1Ширина ткани15801Тип направляющихPA351Тип касетыVEGA1ДекорCOLONIAL3502Количество баластов52Тип струныПластик3Тип ленты127мм Или типа как? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2007, 14:00 |
|
||
|
Где держать данные?
|
|||
|---|---|---|---|
|
#18+
Справочник типов атрибутов (сейчас их 12) + таблица значения атрибутов в увязке с PK той таблицы, где они сечас торчат кучкой. Про хранение объектов и атрибутов в универсальной таблице много можно найти поиском по форуму Проектирование. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2007, 16:10 |
|
||
|
Где держать данные?
|
|||
|---|---|---|---|
|
#18+
2 ByKiS В табл. TblPayments поле PaymentType. В то же время в табл. TblPaymentsTypes есть поле PaymentTypeID. Почему вы предпочли хранить сам тип вместо его ID? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2007, 18:52 |
|
||
|
Где держать данные?
|
|||
|---|---|---|---|
|
#18+
Название поля там PaymentType, но хранится integer. Также, как и в tblOrders в Customer хранится СustomerID из tblCustomers. Или я не понял замечания? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2007, 18:57 |
|
||
|
Где держать данные?
|
|||
|---|---|---|---|
|
#18+
Такая таблица Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2007, 19:01 |
|
||
|
Где держать данные?
|
|||
|---|---|---|---|
|
#18+
Кстати, у вас нет единого стиля именования полей - то у вас FK с суффиксом ID (как в таблице-справочнике), то без... Я бы сделал везде как таблиуе-спрравочнике с суффиксом ID... Пускай безобразно, но единообразно! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2007, 08:38 |
|
||
|
Где держать данные?
|
|||
|---|---|---|---|
|
#18+
Программист-ЛюбительПускай безобразно, но единообразно! Пасибо, учту! Читаю Реддика ;) Ещё вопрос по сарвочнику работников: Каждый работник может выступать в роли манагера или (и) монтажника, или (и) консултанта. Привидилась вчера перед сном такие две схемы. Подскажите которая правильнее была бы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2007, 09:47 |
|
||
|
Где держать данные?
|
|||
|---|---|---|---|
|
#18+
Программист-ЛюбительВерхняя. А в "манагер" и "консультант" в таблице заказов вставлять ИД_сотрудника или ИД_работника ? Стоко времени прошло, а ло меня всё не доходит :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.03.2007, 09:50 |
|
||
|
Где держать данные?
|
|||
|---|---|---|---|
|
#18+
Можно и так и так, но ест некоторый нюанс в последующем использовании. Если вставить ИД_Сотрудника, то из заказа легко можно будет получить информацию о должности, но для выковыривания фамилии нужно будет подключить еще таблицу Работники. Наоборот, если хранить ИД_Работника, то его фаимилия будет доставаться проще, а должность - наоборот через еще одно дополнительное соединение таблиц. По смыслу и идеологически правильнее первое, так как с заказом работает конкретное должностное лицо и с должностью и с фамилией. Еще в такого рода таблицах ОБЯЗАТЕЛЬНО надо сразу делать историю - при перемещении людей с должности на должность запросы по старым данным будут работать неверно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.03.2007, 10:32 |
|
||
|
Где держать данные?
|
|||
|---|---|---|---|
|
#18+
Ситуация вот какая - манагер получает зарплату 5% от заказа, консультант - 2%, замерщик - 1% и т.д. Эти поля (манагер, консультант... - обязательные, т.к. клиента всегда надо проконсультировать, обмерить и выполнить заказ). Заказ можно анулировать - это может только руководитель проекта (на схеме его нет, но он есть). Если меджер принёс свой заказ то он должен получить и за консультанта и за менеджера, т.е. некоторые манагера могут выступать и в роли манагера и в роли консультанта. Руководитель проекта тоже может другу подарить жалюзю - значит он тоже может выступать и роли манатера и в роли консультанта. Некоторые операции может выполнитть только директор. Ещё есть Быков и другие акционеры, которые суются в дела фирмы и могут выступать под ролью директора, руководителя, манагера и т.д. В конце месяца вся сумма за все заказы должна быть поделена между сотрудниками (потому и не могут быть пустые поля) и посчитана зарплата. Может тут вообще надо по другому делать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.03.2007, 10:53 |
|
||
|
Где держать данные?
|
|||
|---|---|---|---|
|
#18+
Если часты явления, когда сотрудники в заказах имеют разные должности, то лучше в таблице заказов сделать и ID должности и ID сотрудника и на момент формирования заказа сохранять туда значения по текущей ситуации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.03.2007, 13:22 |
|
||
|
Где держать данные?
|
|||
|---|---|---|---|
|
#18+
Не понял, так чтоли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.03.2007, 15:10 |
|
||
|
Где держать данные?
|
|||
|---|---|---|---|
|
#18+
ByKiSНе понял, так чтоли? IMHO лучше сделать многие-ко-многим DutiesByOrders создаем ордер tblOrders определяем ответсвенность tblAssignments назначем ответственных tblEmployees ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.03.2007, 15:16 |
|
||
|
Где держать данные?
|
|||
|---|---|---|---|
|
#18+
зоранее благодареньIMHO лучше сделать многие-ко-многим DutiesByOrdersКак многие ко многим? Заказ то один... Поясните, а то я теперь ещё больше не понял. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.03.2007, 15:23 |
|
||
|
Где держать данные?
|
|||
|---|---|---|---|
|
#18+
ByKiS зоранее благодареньIMHO лучше сделать многие-ко-многим DutiesByOrdersКак многие ко многим? Заказ то один... Поясните, а то я теперь ещё больше не понял. а исполнителей по заказу тоже всегда один? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.03.2007, 15:38 |
|
||
|
Где держать данные?
|
|||
|---|---|---|---|
|
#18+
>Не понял, так чтоли? ИМХО гут. Еще уникальность duty_id + order_id. Ведь в данном заказе лишь один манагер, один консультант и т.д.? 2 Программист-Любитель В свете последних разъяснений история наверно не нужна - сотрудника не обязательно назначать на должность манагера чтобы он исполнял роль манагера в заказе. Хотя может с консультантами другая история. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.03.2007, 15:41 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=34415422&tid=1544610]: |
0ms |
get settings: |
6ms |
get forum list: |
18ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
177ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
77ms |
get tp. blocked users: |
1ms |
| others: | 212ms |
| total: | 507ms |

| 0 / 0 |
