|
|
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
Сергей ВаскецовstiУ Поставщика есть прайс-лист, по которому покупают Покупатели (упрощенно). А у Покупателя есть прайс-лист, по которому продают Поставщики (не менее упрощенно). Если не вдаваться в тонкости ценообразования, ибо сейчас это просто неважно, кто и как формирует прайс-лист, то сам по себе прайс-лист (как перечень актуальных цен на позиции номенклатуры для определенной группы контрагентов) применим как при продажах, так и при покупках. Что тут можно еще обсуждать? Я ж не спорю, что вообще это так. Но в нашем случае нет у нас прайс-листа Покупателя и быть не может. Это специфика. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2008, 13:20:11 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
Сколько людей - столько мнений... Предложение по поиску решения проблемы: Если сначала денормализовать задачу следующим образом: слить все в одну таблицу! За чем мы следим? Если за выполнением договорных отношений, даже проще - за договорами на поставку/приобритение товаров/услуг, то в каждой строке нашей таблицы будут: реквизиты покупателя, реквизиты продавца, реквизиты условий договора, реквизиты товара/услуги, многие другие условия, например реквизиты прайса и конкретная его строка. Теперь начинаем постепенно нормализовать: Выделяем таблицу контрагентов - в нее войдут все реквизиты, одинаковые (по сути) для продавцов и потребителей, тогда в основной таблице вместо этих реквизитов для продавца и покупателя останутся ссылки на их записи в таблице контрагентов. (я не слишком нуден?) Однако, в основной таблице остаются еще специфичные реквизиты, относящиеся к продавцу и покупателю. Куда их девать?! Далее, имеет смысл выделить сделки, позиции товаров/услуг.... Потом еще и еще... На каком этапе остановиться? Ответ зависит на 100% от того - что собственно мы хотим учитывать. Какова специфика задачи. Например, можно особенности поставщика и покупателя вынести на уровень параметров договора или сделки, а можно на уровень НСИ, чтобы использовать где-то еще. Нормализация была придумана в том числе и для того, чтобы уменьшить (исключить) дублирование данных. А будет ли оно в том или ином варианте? Если да, то в каком объеме? Ответ на эти вопросы - целиком в специфике. Видел я реализации, в которых существовала промежуточная таблица, в которой всегда была ровно одна запись. Смысла такая таблица не имеет вообще. В другой реализации бизнес-логики она имела бы смысл (при том же ПО), в реализованной - нет. Если АВТОР собрался сделать что-то супер-мега-универсальное (на все случаи жизни) - флаг ему в руки. Работать такая система не будет никогда и ни где. Пример - ERP-системы: хоть они и не "супер-мега-универсальные", но с претензией. Поэтому в чистом виде не подходят ни одному предприятию. Чтобы запустить - нужно "долго дорабатывать напильником" под конкретное предприятие и после этого на предприятии будут долго еще плеваться по поводу того, что получили. Если нечто конкретное - нужно конкретно и задавать вопрос: как реализовать конкретную функциональность, а не "сколько таблиц лучше: две, одна или пятнадцать?" Короче, тема исчерпалась! Пора ее закрывать! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2008, 15:41:12 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
Сергей Васкецов Никак не нравится. Чтобы платежные реквизиты стали лицевыми счетами, необходимо, чтобы дело происходило в банке, к тому же "лицевой счет" - сильно обобщенное понятие. А уж "расчеты с контрагентами" вообще не в тему, это никакие не расчеты. Можете назвать "расчетные счета", это более нейтрально и корректно, если не вдаваться в дебри SWIFT и его форматов, хотите - добавьте прилагательное "банковский" в сответствующем числе и падеже. Вы идею не поняли, к платежным (банковским) реквизитам это никакого отношения не имеет. На этих регистрах накапливаются суммы отгрузок (поставок). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2008, 08:53:28 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
andreychВы идею не поняли, к платежным (банковским) реквизитам это никакого отношения не имеет. На этих регистрах накапливаются суммы отгрузок (поставок). Тогда называйте как хотите. Впрочем, я вообще не понимаю, зачем это отдельно от первички "накапливать", но хозяин - барин. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2008, 15:43:40 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
На моём предприятии БД для задачи учёт материальных ценностей на складах цехах и материально-отв лицах организовал следующим образом: имеется справочник контрагентов следующей структуры: СТРУКТУРА SP_AG-справочник контрагентов ID_AGN I(4,0) идентификатор контрагента NAM C(40,0) наименование контрагента K_POST N(4,0) код поставщика,покупателя K_CEX N(3,0) код цеха TAB_N N(8,0) табельный № K_IZD N(4,0) код изделия В этом справочнике поле ID_AGN - идентификатор контрагента формируется автоматечески. Если контрагент явл. материально-отв лицом, то поле TAB_N принимает значение табельного № этого лица,а поля K_POST,K_CEX,K_IZD принимают значение 0,аналогично для других типов контрагента Этот справочник ежедневно обновляется за счет НСИ из других БД. Для хранения документов,отражающих движение мат.ценностей на предприятии используются следующие две таблицы: СТРУКТУРА DOK-шапка документа ID_DOK I(4,0) идентификатор документа D_DOK D(8,0) дата документа OTP I(4,0) идентификатор отправителя POL I(4,0) идентификатор получателя K_DOK C(3,0) код документа N_DOK C(10,0) № документа SUMA N(18,2) сумма документа СТРУКТУРА DOKS-детальные строки документа ID_STR I(4,0) идентификатор детальной строки документа ID_TOV I(4,0) идентификатор товара,материала CENA N(16,8) цена товара KOL N(15,3) количество SUMA N(18,2) сумма товара ID_DOK I(4,0) идентификатор документа При такой организации БД поступление мат.ценности от поставщика на предприятие в табл.DOK отразится следующим образом:поле OTP -идентификатор поставщика, POL-идентификатор склада,а расход мат.ценности на производство продукции отразится так:OTP -идентификатор цеха,POL-идентификатор изделия. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2008, 12:05:51 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
LUCIAN СТРУКТУРА DOKS-детальные строки документа ID_STR I(4,0) идентификатор детальной строки документа ID_TOV I(4,0) идентификатор товара,материала CENA N(16,8) цена товара KOL N(15,3) количество SUMA N(18,2) сумма товара ID_DOK I(4,0) идентификатор документа Что-то не спится. Из выделенного оставьте любые два. Третий лишний. Обычно выбрасывают цену (в данных, НЕ в формах ввода доков). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2009, 05:25:21 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
LUCIAN СТРУКТУРА DOKS-детальные строки документа ID_STR I(4,0) идентификатор детальной строки документа ID_TOV I(4,0) идентификатор товара,материала CENA N(16,8) цена товара KOL N(15,3) количество SUMA N(18,2) сумма товара ID_DOK I(4,0) идентификатор документа Что-то не спится. Из выделенного оставьте любые два. Третий лишний. Обычно выбрасывают цену (в данных, НЕ в формах ввода доков). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2009, 05:26:38 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
Папа Игорь Из выделенного оставьте любые два. Третий лишний. Обычно выбрасывают цену (в данных, НЕ в формах ввода доков). То что третий лишний - точно. Но я бы выкинул сумму. Деление - более опасная операция, чем умножение :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.01.2009, 09:34:57 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
Cat2То что третий лишний - точно. Но я бы выкинул сумму. Деление - более опасная операция, чем умножение :) Здравствуйте! Категорически не согласен. Обосную. Мы должны ХРАНИТЬ наиболее точные данные. Если принять Ваш вариант(выбрасываем сумму), то нельзя точно сохранить такую пару: 3 шт. на сумму 1 руб. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2009, 18:18:11 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
Добавлю. В базе хранятся данные /вот, блин, как просто :-) / и если надо хранить какое-то количество и его денежное выражение (в нашем случае), то и поступаем так, т.е. сумму. Одна из моих профессий - это бухучет (21 год). Еще в начале своей карьеры услышал и принял следующее - Цена величина расчетная. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2009, 18:33:38 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
Опять добавлю. Лично я (в приложениях по бухучету) практически никогда не храню количество. Разбиваю всю партию на минимально оперируемые кванты и храню только стоимость этих квантов, полученную расчетным путем. Тогда в выше приведенном примере (3 шт. на сумму 1 руб.) получаем три записи в таблице: Что-то типа: prod1 0,33 prod1 0,33 prod1 0,34 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2009, 18:48:52 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
Папа Игорь, Как это не хранить количества? А если 100 шт. по 1 коп. - будет 100 квантов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2009, 01:11:04 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
Папа Игорь, Прошу прощения, был невнимателен к структуре примера. Я имел ввиду, что хранить сумму - опасно для базы в той ее части, где учитываются остатки. Что бы не получить "0 шт. на сумму 10 рублей". Бывает такое, при ошибках ввода. ============= В той части где хранятся документы на отпуск товара, действительно надо хранить сумму. Иначе просто невозможно, например, учитывать в цене всякие натуральные (не процентные) скидки с общей суммы. ========== Знаем мы как бухи считают, совсем не так, как налоговая и не так, как в математике :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2009, 01:35:05 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
Cat2Я имел ввиду, что хранить сумму - опасно для базы в той ее части, где учитываются остатки. Что бы не получить "0 шт. на сумму 10 рублей". Бывает такое, при ошибках ввода. Ну а в остатках тем более надо сумму хранить, а не цену. А "0 шт. на сумму 10 рублей" - можно разрешить, это тоже, что и курсовая разница. Может иногда возникать и штатно... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2009, 02:33:00 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
шПапа Игорь, Как это не хранить количества? А если 100 шт. по 1 коп. - будет 100 квантов? Здравствуйте! Минимально оперируемые кванты (в контексте моего сообщения) - это не 1 шт. Это может быть и кг, и тонна, и литр, и т.п. Смысл в том, чтобы выбрать наименьшую единицу измерения количества/объема. Если у вас угольная шахта. Добываете в сутки 50 000 тыс.тонн. Какой "квант" выберете. Я - тонну. А если вы ювелир. Квантик получается другой. :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2009, 14:11:19 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
Папа Игорь, согласен. Но с формальной точки зрения: как не хранить количества? Если квант = т (в Вашем примере), то 50000 записей вместо одной? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2009, 14:17:03 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
ш...Если квант = т (в Вашем примере), то 50000 записей вместо одной? А что мешает? :-) Если бы Вы знали насколько при этом упрощаются некоторые учетные задачи. Или мы нарушаем какие-либо теоритические постулаты? Просто производим декомпозицию до необходимого нам уровня. Мы уже удалились от темы ветки. Давайте закруглятся. Согласны? Успехов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2009, 15:41:56 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
ш, Папа Игорь Но с формальной точки зрения: как не хранить количества? Если квант = т (в Вашем примере), то 50000 записей вместо одной? В некоторых задачах количество не нужно. Например, та же добыча: если добываете абстрактные тонны, то зачем количество? Другой вопрос, что этот уголь вы кладете в вагоны, тогда имеет смысл кроме веса еще и учитывать вагоны. Другими словами нужно учитывать те объекты, за которыми следим! Назвать их можно как угодно. Наиболее частые названия: партия, субпартия, либо конкретно: пачка, бочка, багон, штучка... В БД можно сделать любую разбивку вплоть до милиграм (для добычи угля), но потом с ней будут (или не будут?) работать люди. Как вы сможете учесть от которой тонны угля не досчитались? Начнете говорить про ФИФО-ЛИФО - зачем тогда вообще такая детализация, если она полностью нивелируется кодом? У меня один ответ - чтобы программисту было чем заняться, другого смысла не вижу. Все ИМХО, ничего личного к собеседникам ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2009, 07:51:57 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
KOT MATPOCKuH, можете открыть новую тему "Кванты вместо натуральных измерителей". Тема то интересная, но у меня мозги не варят, как это осуществить... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2009, 09:28:32 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
ш...Кванты вместо натуральных измерителей... Натуральные числа - знаю. Натуральные измерители - не знаю. Идея проста, как ... Вы делаете декомпозицию данных до такого уровня при котором все множество этих данных является однородным (в контексте задачи). SQL хорошо работает с множествами. Масштаб хранимых единиц измерения выбирается такой, что верно следующее: одна запись равна одной единице измерения. Сравните: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. В первом случае операция над множеством, во втором - модификация атрибута. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2009, 12:36:45 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
Папа Игорь...В первом случае операция над множеством, во втором - модификация атрибута. Возможно мой подход уже старомоден. :-) Но я привык хранить информацию в БД в виде записей. И изменять ее (информацию) работая с записями. А модифицировать атрибуты только для исправления ошибок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2009, 12:47:06 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
Папа Игорь, благодарю! Не знаю откуда, но у меня засело в голове, что: Сумма (руб/валюта), Кол-во - это "Измерители", а "41","Петров","Носки" - это значения, координаты точки в "пространстве хоз.операций", где Оси или "Измерения" - это "Синт.счет", "МОЛ", "ТМЦ" и др... А как правильно говорить? При вводе партии (3 шт. на сумму 1 руб.) получаем три записи в таблице. Эти записи и являются мин.квантом в вашей БД или точкой в пр-ве. Так? Можете дать типовой состав этой точки (схему таблицы партий)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2009, 14:37:24 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
ш...При вводе партии (3 шт. на сумму 1 руб.) получаем три записи в таблице. Эти записи и являются мин.квантом в вашей БД или точкой в пр-ве. Так? Можете дать типовой состав этой точки (схему таблицы партий)? Здравствуйте! Не отвечая именно на этот Ваш вопрос, постараюсь упростить (без потери качества). Термин «квант» использовал потому, что , имхо, он более подходит для того, что мы имеем ввиду, говоря об «атомарности данных». Не в терминах дело. Дело в соблюдении принципа «атомарности данных». В учебной литературе, освещая вопросы нормализации, часто приводят пример с телефонными номерами. В одном поле таблицы хранится несколько номеров телефонов: "555-4124; 555-7852…" Плохо это? Говорят, что плохо. А почему? Не будем рассуждать о сложности модификации, поиска и т.п. Рассмотрим ИСПОЛЬЗОВАНИЕ. Практически во всех случаях использования мы будем оперировать ЧАСТЬЮ значения этого поля. Тогда зачем их хранить вместе. Давайте разобьем это значение на используемые порции - кванты в моей терминологии. Если номер всегда используется для звонков, то будем хранить полные номера, а если нам требуется делать анализ по телефонным узлам, то квантование продолжим дальше. Так и с количеством (в нашем примере). Если значение "3 шт" мы ВСЕГДА будем использовать как "3 шт.", то и хранить надо в таком виде. Но если возможен вариант использования ЧАСТИ значения поля (например - "1 шт."), то и хранить в БД надо эти ЧАСТИ. Мой подход к нормализации следующий: нормализую полностью при проектировании – денормализую (по разным причинам) при реализации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2009, 14:38:34 |
|
||
|
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
|
|||
|---|---|---|---|
|
#18+
Папа Игорь! Идея ваша уже раньше была понятна, но развернутое изложение еще усугубило это понимание, спасибо. Будем знать и применять, когда уместно будет. Вопросы были "по касательной". 1) Пространство, Оси, Точки, Значения. Эти термины м.б. и применимы к учету, но общеприняты ли? Скорее нет. Вы поправили меня в терминах, вот я и попробовал выяснить попутно, какие правильные слова следует употреблять. 2) Хранение квантов можно по разному устроить. Видимо в таблице "Партии". Вот я и хотел убедиться (проверив состав записи), что верно догадался... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2009, 20:04:38 |
|
||
|
|

start [/forum/topic.php?fid=32&gotonew=1&tid=1543488]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
177ms |
get topic data: |
8ms |
get first new msg: |
5ms |
get forum data: |
2ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
| others: | 225ms |
| total: | 481ms |

| 0 / 0 |
