Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Структура таблиц с накладными
|
|||
|---|---|---|---|
|
#18+
Разрабатываю новую версию склада. Дошел до переделки накладных. Сейчас у меня 4 таблицы с одинаковой структурой для накладных прихода, расхода, возврата и перемещения между складами. Есть большой соблазн запихать это все в одну таблицу разделив только признаком тип накладной. Кто нибудь подскажите где можно наколоться, какие минусы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 08:07 |
|
||
|
Структура таблиц с накладными
|
|||
|---|---|---|---|
|
#18+
Если они у тебя отличаюцца только типом, тогда все пучком - делаешь 2 таблицы: накладные и типы_накладных и все, но если у них есть различные аттрибуты, характерные только для одного из типов накладных, тады ето дорогой товарисч обычная ролевая структура. Делаешь так: 1. создаешь таблицу "Абстрактные накладные" 2. вытаскиваешь в нее все ОДИНАКОВЫЕ для ВСЕХ типов накладных атрибуты 3. для каждого типа накладных, у которых есть непопавшие в главную таблицу атрибуты, создаешь свою совственную таблицу, имеющую foreignkey на "Абстрактные накладные"... вот и все... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 08:55 |
|
||
|
Структура таблиц с накладными
|
|||
|---|---|---|---|
|
#18+
Делай отдельными таблицами, не ленись. В будущем это тебя избавит от огромного гемора, если придется изменить-добавить поле, например ссылку на экспедитора в расходной - придется менять все что связано с обобщенной накладной, а так только с расходной. И так далее. Я сделал себе скрипт, создающий обобщенный документ, а дальше ручками добавляю-изменяю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 09:32 |
|
||
|
Структура таблиц с накладными
|
|||
|---|---|---|---|
|
#18+
Согласен c Denis___Ka Накладные должны распологаться в одной таблице. В "заголовке" накладной имеется поле SRC_ID (источник) и DST_ID (получатель). Данные поля ссылаются либо на внутренние подразделения (складские организации), либо на внешних контрагентов. В зависимоси от источника и получателя можно определить тип накладной: внешний приход, внутренние приход (расход) и тд и тп. Конечно, можно и не осуществлять данный анализ, если вы хотите ввести доп поле тип накладной . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 09:40 |
|
||
|
Структура таблиц с накладными
|
|||
|---|---|---|---|
|
#18+
Зачем их складывать в одну таблицу, какой смысл кроме кажущейся красоты на первом этапе? Начнем с того что уникальная нумерация будет сопряжена с типом документа, если нужны какието связи, придется вязать ее масу на себя итд итп. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 10:11 |
|
||
|
Структура таблиц с накладными
|
|||
|---|---|---|---|
|
#18+
TimKa Начнем с того что уникальная нумерация будет сопряжена с типом документа, если нужны какието связи, придется вязать ее масу на себя итд итп. Подход уникальной нумерации в зависимости от типа документа и есть разделение накладных в отдельные таблицы. При хранении в одной таблице уникальная нумерация (Primary Key) не зависит от типа накладной - она сквозная .... Про связи - легче сделать их для одной таблицы, нежели повторять их (порой один в один дублировать) для нескольких... Вообщем пусть каждый отставивает свою точку зрения - лично мое твердое убеждение - таблица должна быть одна. (даже имеется многолетний положительный опыт работы с такой структурой :-))) ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 10:38 |
|
||
|
Структура таблиц с накладными
|
|||
|---|---|---|---|
|
#18+
Согласен c Denis___Ka Но различные поля вовсе необязательно выносить... Пущай живут вместе, они друг другу не мешают... (тем более если их всего несколько) У меня, например, весь расчет производится автоматически триггерами при занесении соответствующего признака... Вот бы их писать их на четыре таблицы... или четыре ХП обработки... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 10:39 |
|
||
|
Структура таблиц с накладными
|
|||
|---|---|---|---|
|
#18+
Я говорю про связи между документами. В случае, если таких связей несколько, ваша таблица будет выглядеть клубком, если вообще возможно будет связать. Сквозная нумерация по всем типам документов тем более не интересно - если завтра выйдет закон о сквозной нумерации накладных на отгрузку, как неоднократно было, что в такой структуре будете делать с Primary Key для всех документов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 11:05 |
|
||
|
Структура таблиц с накладными
|
|||
|---|---|---|---|
|
#18+
olol У меня, например, весь расчет производится автоматически триггерами при занесении соответствующего признака... Вот бы их писать их на четыре таблицы... или четыре ХП обработки... Так они все равно для каждого документа свои, или у вас триггер делает одно и то же для всех документов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 11:13 |
|
||
|
Структура таблиц с накладными
|
|||
|---|---|---|---|
|
#18+
еще раз: Главная задача проектировщика - Добиться как можно большей степени нормализации используя как можно меньшее количество объектов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 11:14 |
|
||
|
Структура таблиц с накладными
|
|||
|---|---|---|---|
|
#18+
TimKa что в такой структуре будете делать с Primary Key для всех документов? мы говорим о разных понятиях - номер документа и ID документа (сответственно PK ) . И в случае необходимости, никто не мешает вычислять номер документа (если это действительно НОМЕР) как max+1 для соответствующего типа накладной (в принципе можно для каждого типа накладной в отдельной табличке сохранять номер, затем считывать и инкрементировать - при этом на данную операцию будет расходоваться минимальное кол-во серверных ресурсов Это уже частности реализации). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 11:21 |
|
||
|
Структура таблиц с накладными
|
|||
|---|---|---|---|
|
#18+
Все же не вижу смысла вносить путаницу в структуру данных, выносить поля в отдельные таблицы, а основные держать в общей. Скажите хоть один довод за, или приведите пример, по производительности, или по удобству выборки и я замолчу :) Единственное удобство - если все проводки содержатся в документах а не отдельных регистрах, тогда одним простым селектом можно выбрать и приходы и расходы, к примеру. Но это годится только для примитивной системы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 12:01 |
|
||
|
Структура таблиц с накладными
|
|||
|---|---|---|---|
|
#18+
TimKaвыносить поля в отдельные таблицы Структура накладных одна и та же , поэтому выносить поля в отдельные таблицы не нужно. По поводу отдельной сквозной нумерации для каждой накладной и вынесения последнего номера для каждого типа в отдельную таблицу (денормализация) - это пример для экономии ресурсов сервера (этого можно и не делать и просто работать по max(Number)+1 ) УСЕ!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 12:21 |
|
||
|
Структура таблиц с накладными
|
|||
|---|---|---|---|
|
#18+
TimKa …если придется изменить-добавить поле, …придется менять все что связано с обобщенной накладной, а так только с расходной. Зачем менять другие формы ? Ну добавил ты хоть 10 полей в один тип накладной, а причем тут другие ? На других формах будут только те поля, с которыми они работают. Одно другому не мешает. TimKa Так они все равно для каждого документа свои, или у вас триггер делает одно и то же для всех документов? Конечно не один, а три: на INSERT,DELETE и UPDATE для всех документов. И в зависимости от источника/получателя производятся соответствующие действия. Правда, Источник/Получатель у меня тоже в одной таблице с соответствующим признаком… А вот если они разбиты на несколько…, то тогда связки, конечно, усложняются… vooo …в отдельной табличке сохранять номер... ID лучше брать не из таблички, а из генератора (для большей надежности). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 13:08 |
|
||
|
Структура таблиц с накладными
|
|||
|---|---|---|---|
|
#18+
[quot vooo] Структура накладных одна и та же , поэтому выносить поля в отдельные таблицы не нужно. [quot] Пока не нужно. Пока не пришел началник и не попросил в отгрузочную добавить номер ГТД, к примеру. По поводу денормализации спорить не буду, так как это вопрос тонкий - как хранить данные - в нормализованом виде или в куче, и не может служить аргументом, так как вопрос экономии вычислительных ресурсов при денормализации встает боком при обработке данных, и прогнозировать трудно, что будет проще для сервера. Я уж не говорю о целостности данных и прочем, отчего эта самая нормализация придумана старыми дядьками. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 13:21 |
|
||
|
Структура таблиц с накладными
|
|||
|---|---|---|---|
|
#18+
По поводу плюсов объединения накладных в одну таблицу. При проектировании каждой таблицы я ставлю вопрос: какие задачи решают объекты, содержащиеся в данной таблице. Для всех четырех таблиц у меня получаются 2 основные задачи : 1- изменение остатков на складе (на складах) 2- изменение текущего сальдо у контрагентов участвующих в операции остальные производные от этих двух функций. Таким образом, суть объектов во всех четырех таблицах одна и та же. Логично объединить эти объекты (накладные) в одну таблицу. Вносить индивидуальные особенности, например, отдельной нумерации для каждого типа меня не затруднит. Меня интересовали как раз моменты, когда я сделал процентов 70 всех отчетов, и заказчик просит сделать что то, что гарантированно можно сделать только с извращениями в особо циничной форме : ). Именно о таких моментах я и спрашивал. По тому, как народ отвечает, таких ситуаций у тех, кто использует подобную структуру не возникало. Если я не прав – остановите меня, пока я не ушел слишком далеко. А то я уже ХП писать начал : ). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 13:23 |
|
||
|
Структура таблиц с накладными
|
|||
|---|---|---|---|
|
#18+
авторНа других формах будут только те поля, с которыми они работают. Одно другому не мешает. Насколько я понял, предлагается просто оставлять nulls или заранее условленные значения для тех полей что неиспользуются? Это очень плохой стиль, мне кажется, и гораздо безобразнее выглядит, чем отвести под каждый документ отдельную таблицу, если мы говорим о красоте авторИ в зависимости от источника/получателя производятся соответствующие действия. Значит, код в них все таки разный для разных документов. Ну и чем это отличается от того, что вы разнесете этот код по разным триггерам, вместо того чтобы громоздить эти CASE и IF ? авторПравда, Источник/Получатель у меня тоже в одной таблице с соответствующим признаком… Имеется ввиду, что один и тот же справочник? Это как раз не смертельно, хотя я бы разделил справочник складов и клиентов к примеру. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 13:28 |
|
||
|
Структура таблиц с накладными
|
|||
|---|---|---|---|
|
#18+
[quot TimKaЯ уж не говорю о целостности данных и прочем, отчего эта самая нормализация придумана старыми дядьками.[/quot] Простите, а где я нормализацию нарушаю. Если в нумерации, то у меня требование к нумерации накладных каждый месяц начинать ее заново - так что в любом случае придется хранить номер следующей накладной. Обрабатывать накладные по таким номерам можно только по ключу номер-дата. А я таким ключам предпочитаю синтетические. Id в объединенний табличке и id в четырех раздельных особых различий не несут... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 13:29 |
|
||
|
Структура таблиц с накладными
|
|||
|---|---|---|---|
|
#18+
Простите, а где я нормализацию нарушаю. это vooo ответ был про денормализацию. Вобщем, если структура менятся не будет, и вам не придется поддерживать эту базу, то делайте в одной таблице. Добавление одного поля в один из типов документов нарушит нормализацию, если говорить о ней, со всеми вытикающими гемороями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 13:40 |
|
||
|
Структура таблиц с накладными
|
|||
|---|---|---|---|
|
#18+
TimKa …оставлять nulls или… Это очень плохой стиль… …безобразнее выглядит, чем отвести под каждый документ отдельную таблицу… Если сейчас есть четыре типа накладных: приход, расход, возврат и перемещения между складами то, как быть в случае появления учета для фиктивных складов (например: учет в цехе со своими особенностями), где документы несколько отличаются от реальных складов? Добавлять новые таблички для этих документов? (чтоб не было лишних полей с null). Даже простой расход для внутреннего производства и продажу – тоже в разных табличках или указывать ‘пустого’ покупателя? Это тоже самое - как каждый вид товара хранить в отдельной таблице… TimKa …громоздить эти CASE и IF ? В любом случае, когда обрабатываешь перемещение со склада на склад, ты смотришь, откуда и куда и делаешь однотипные вычисления. Только для прихода будет нулевой расход (и наоборот). alex_ll …заказчик просит сделать что то, что гарантированно можно сделать только с извращениями в особо циничной форме… Если для извращений необходимо будет заносить специальные данные с соответствующей обработкой, то когда все документы в одном месте, то достаточно им задать соответствующий признак, который будет общим для всех видов накладных и не надо будет для них создавать специальные таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 14:40 |
|
||
|
Структура таблиц с накладными
|
|||
|---|---|---|---|
|
#18+
Если сейчас есть четыре типа накладных: приход, расход, возврат и перемещения между складами то, как быть в случае появления учета для фиктивных складов (например: учет в цехе со своими особенностями), где документы несколько отличаются от реальных складов? Именно так и делается в нормальной системе учета имхо, одна производственная операция - один документ - одна система таблиц для хранения данного документа. Потому что понятие "несколько" весьма растяжимо, и под велением времени это "несколько" вырастает в ощутимую "сколько", а в результате у вас получится огромное табло с кучей нулов, зато одно, и один триггер с пятистами ветвлениями, в котором никто, кроме вас не разберется. Другое дело, что никто не заставляет вас конструировать каждый раз эту систему таблиц вручную. Остальное оставляю без коментариев, думаю, выше все рассказал :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 20:48 |
|
||
|
Структура таблиц с накладными
|
|||
|---|---|---|---|
|
#18+
alex_llЕсть большой соблазн запихать это все в одну таблицу разделив только признаком тип накладной. В результате эволюции нашей системы все мы пришли к выводу, что документы должны быть в ОДНОЙ таблице. Может быть, кроме только лишь каких-то извращенных. В новой версии именно так и будет. Завтра напишу плюсы этого, сейчас домой пора :). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 22:53 |
|
||
|
Структура таблиц с накладными
|
|||
|---|---|---|---|
|
#18+
Вы господа обсуждаете широко известные (по Фаулеру и не только) паттерны: Наследование с одной таблицей, Наследование с таблицами для каждого класса и Наследование с таблицами для каждого конкретного класса. А мораль - здесь нет "лучшего" и/или "правильного" решения - для каждого отдельного приложения и проектировщика оно свое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2004, 03:24 |
|
||
|
Структура таблиц с накладными
|
|||
|---|---|---|---|
|
#18+
Вы господа обсуждаете широко известные (по Фаулеру и не только) паттерны Ага, зашел грамотный человек! Жалко что проходящий... Где почитать про это? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2004, 08:59 |
|
||
|
|
start [/forum/topic.php?fid=32&startmsg=32580247&tid=1546382]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
42ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
72ms |
get tp. blocked users: |
1ms |
| others: | 256ms |
| total: | 406ms |
| 0 / 0 |
