| |
|
|
| | добрый вечерок друзья
а вот подскажите в таком вопрос
у меня есть таблица, в которой на данный момент чуть ли не больше полусотни полей
в ней намешаны и финансовые, и производственные вопросы и тд.
Но все эти вопросы относятся к одному заказу
имеет ли смысл разбить таблицу на несколько таблиц и связать их по полю №_Заказа, а воедино собрать ч-з запрос (чтобы получить большую исходную таблицу, как если бы я её не разбивал)...
собрав воедино ч-з запрос, этот запрос все равно держит открытыми все таблички, так в чем тода смысл разбиения? | |
| |
| |
| |
|
|
| | В одной из баз разбил таблицу на две: данные по заказу и реквизиты заказа. Во второй таблице реквизиты покупателя и продавца.
Дело в том, что покупатели и продавцы практически всегда разные, но в то же время нужно было предусмотреть возможность продавать повторно тому же покупателю, не внося заново его реквизиты. Но главная причина выноса таблицы – в заказах должны быть данные и покупателя и продавца. Если все держать в одной таблице заказов (данные заказа и реквизиты покупателей/продавцов) – получится дважды заводить в таблице практически одинаковые поля отдельно для покупателей и продавцов. А это в итоге полей:
Заказы – 30 шт
Реквизиты покупателя = 44 шт
Реквизиты продавца = 44 шт
Итого = 118 шт – чего то до фига для одной таблицы
А при разбиении вышло 30 + 2 кода для покупателя и для продавца
То есть в некоторых частных случаях вынос данных в отдельную таблицу связью 1 – 1 имеет смысл как более наглядное представление структуры базы в схеме данных. Правда вместо двух таблиц (для покупателей и продавцов) я сделал одну с кодом статуса контрагента, то есть схема связи вышла 1 – 2, но это сути не меняет.
Хотя впрочем в данном случае вынос реквизитов помог уменьшить число полей на 44 (за счет кода статуса) - стало быть пример не совсем в тему. | |
| |
| |
| |
|
|
| | Попробуйте абстрагироваться от таблиц и полей и оперировать понятиями сущность(объект, документ) и его атрибуты (свойства)
например "Заказ"
у него есть атрибуты - стоимость, сроки, исполнитель, заказчик, адрес доставки и т.д.
но реквизиты заказчика или реквизиты счета по которым была произведена оплата, к заказу (как к объекту) отношения не имеют.
Взгляните с этой точки зрения на свой тех процесс, и сразу станет понятно, что и куда...
Однозначных рецептов нет, многое зависит от особенностей.
Например если у одного заказчика 10 юр.лиц и их надо выделять отдельно, но при этом нужно получать аналитику в разрезе заказчика (понимая что за юр. лицами "А","В" и "С" стоит один и тот же заказчик) придется это учитывать при создании структуры, а если достаточно аналитики по юр. лицами (не важно что все они представляют одну фирму), то можно этим не заморачиваться.
Так что при одинаковой общей схеме работы с заказами в каждом конкретном случае набор объектов может различаться в зависимости от деталей | |
| |
| |
