powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
24 сообщений из 99, страница 4 из 4
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
    #35663130
sti
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сергей ВаскецовstiУ Поставщика есть прайс-лист, по которому покупают Покупатели (упрощенно).
А у Покупателя есть прайс-лист, по которому продают Поставщики (не менее упрощенно). Если не вдаваться в тонкости ценообразования, ибо сейчас это просто неважно, кто и как формирует прайс-лист, то сам по себе прайс-лист (как перечень актуальных цен на позиции номенклатуры для определенной группы контрагентов) применим как при продажах, так и при покупках. Что тут можно еще обсуждать?
Я ж не спорю, что вообще это так. Но в нашем случае нет у нас прайс-листа Покупателя и быть не может. Это специфика.
...
Рейтинг: 0 / 0
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
    #35663611
KOT MATPOCKuH
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сколько людей - столько мнений...

Предложение по поиску решения проблемы:
Если сначала денормализовать задачу следующим образом: слить все в одну таблицу!
За чем мы следим?
Если за выполнением договорных отношений, даже проще - за договорами на поставку/приобритение товаров/услуг, то в каждой строке нашей таблицы будут:
реквизиты покупателя, реквизиты продавца, реквизиты условий договора, реквизиты товара/услуги, многие другие условия, например реквизиты прайса и конкретная его строка.

Теперь начинаем постепенно нормализовать:
Выделяем таблицу контрагентов - в нее войдут все реквизиты, одинаковые (по сути) для продавцов и потребителей, тогда в основной таблице вместо этих реквизитов для продавца и покупателя останутся ссылки на их записи в таблице контрагентов.

(я не слишком нуден?)

Однако, в основной таблице остаются еще специфичные реквизиты, относящиеся к продавцу и покупателю. Куда их девать?!

Далее, имеет смысл выделить сделки, позиции товаров/услуг....
Потом еще и еще...

На каком этапе остановиться?
Ответ зависит на 100% от того - что собственно мы хотим учитывать. Какова специфика задачи.
Например, можно особенности поставщика и покупателя вынести на уровень параметров договора или сделки, а можно на уровень НСИ, чтобы использовать где-то еще.

Нормализация была придумана в том числе и для того, чтобы уменьшить (исключить) дублирование данных. А будет ли оно в том или ином варианте? Если да, то в каком объеме? Ответ на эти вопросы - целиком в специфике.
Видел я реализации, в которых существовала промежуточная таблица, в которой всегда была ровно одна запись. Смысла такая таблица не имеет вообще. В другой реализации бизнес-логики она имела бы смысл (при том же ПО), в реализованной - нет.

Если АВТОР собрался сделать что-то супер-мега-универсальное (на все случаи жизни) - флаг ему в руки. Работать такая система не будет никогда и ни где. Пример - ERP-системы: хоть они и не "супер-мега-универсальные", но с претензией. Поэтому в чистом виде не подходят ни одному предприятию. Чтобы запустить - нужно "долго дорабатывать напильником" под конкретное предприятие и после этого на предприятии будут долго еще плеваться по поводу того, что получили.

Если нечто конкретное - нужно конкретно и задавать вопрос: как реализовать конкретную функциональность, а не "сколько таблиц лучше: две, одна или пятнадцать?"

Короче, тема исчерпалась!
Пора ее закрывать!
...
Рейтинг: 0 / 0
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
    #35664597
andreych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Сергей Васкецов
Никак не нравится. Чтобы платежные реквизиты стали лицевыми счетами, необходимо, чтобы дело происходило в банке, к тому же "лицевой счет" - сильно обобщенное понятие. А уж "расчеты с контрагентами" вообще не в тему, это никакие не расчеты. Можете назвать "расчетные счета", это более нейтрально и корректно, если не вдаваться в дебри SWIFT и его форматов, хотите - добавьте прилагательное "банковский" в сответствующем числе и падеже.

Вы идею не поняли, к платежным (банковским) реквизитам это никакого отношения не имеет. На этих регистрах накапливаются суммы отгрузок (поставок).
...
Рейтинг: 0 / 0
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
    #35665994
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andreychВы идею не поняли, к платежным (банковским) реквизитам это никакого отношения не имеет. На этих регистрах накапливаются суммы отгрузок (поставок).
Тогда называйте как хотите. Впрочем, я вообще не понимаю, зачем это отдельно от первички "накапливать", но хозяин - барин.
...
Рейтинг: 0 / 0
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
    #35667641
LUCIAN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
На моём предприятии БД для задачи учёт материальных ценностей на складах
цехах и материально-отв лицах организовал следующим образом:
имеется справочник контрагентов следующей структуры:

СТРУКТУРА 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-идентификатор изделия.
...
Рейтинг: 0 / 0
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
    #35744504
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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) идентификатор документа


Что-то не спится.

Из выделенного оставьте любые два. Третий лишний. Обычно выбрасывают цену (в данных, НЕ
в формах ввода доков).
...
Рейтинг: 0 / 0
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
    #35744505
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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) идентификатор документа


Что-то не спится.

Из выделенного оставьте любые два. Третий лишний. Обычно выбрасывают цену (в данных, НЕ
в формах ввода доков).
...
Рейтинг: 0 / 0
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
    #35744540
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Папа Игорь

Из выделенного оставьте любые два. Третий лишний. Обычно выбрасывают цену (в данных, НЕ
в формах ввода доков).
То что третий лишний - точно. Но я бы выкинул сумму. Деление - более опасная операция, чем умножение :)
...
Рейтинг: 0 / 0
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
    #35746049
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cat2То что третий лишний - точно. Но я бы выкинул сумму. Деление - более опасная операция, чем умножение :)

Здравствуйте!

Категорически не согласен. Обосную.

Мы должны ХРАНИТЬ наиболее точные данные. Если принять Ваш вариант(выбрасываем сумму),
то нельзя точно сохранить такую пару: 3 шт. на сумму 1 руб.
...
Рейтинг: 0 / 0
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
    #35746067
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Добавлю.

В базе хранятся данные /вот, блин, как просто :-) / и если надо хранить
какое-то количество и его денежное выражение (в нашем случае), то и поступаем так, т.е.
сумму.

Одна из моих профессий - это бухучет (21 год). Еще в начале своей карьеры услышал и принял
следующее - Цена величина расчетная.
...
Рейтинг: 0 / 0
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
    #35746087
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Опять добавлю.

Лично я (в приложениях по бухучету) практически никогда не храню количество. Разбиваю всю партию на минимально оперируемые кванты и храню только стоимость этих квантов, полученную расчетным путем.

Тогда в выше приведенном примере (3 шт. на сумму 1 руб.) получаем три записи в таблице:

Что-то типа:
prod1 0,33
prod1 0,33
prod1 0,34
...
Рейтинг: 0 / 0
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
    #35748168
ш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ш
Гость
Папа Игорь,
Как это не хранить количества? А если 100 шт. по 1 коп. - будет 100 квантов?
...
Рейтинг: 0 / 0
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
    #35748181
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Папа Игорь,

Прошу прощения, был невнимателен к структуре примера.
Я имел ввиду, что хранить сумму - опасно для базы в той ее части, где учитываются остатки.
Что бы не получить "0 шт. на сумму 10 рублей".
Бывает такое, при ошибках ввода.
=============
В той части где хранятся документы на отпуск товара, действительно надо хранить сумму.
Иначе просто невозможно, например, учитывать в цене всякие натуральные (не процентные) скидки с общей суммы.

==========
Знаем мы как бухи считают, совсем не так, как налоговая и не так, как в математике :)
...
Рейтинг: 0 / 0
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
    #35748206
ш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ш
Гость
Cat2Я имел ввиду, что хранить сумму - опасно для базы в той ее части, где учитываются остатки.
Что бы не получить "0 шт. на сумму 10 рублей".
Бывает такое, при ошибках ввода.

Ну а в остатках тем более надо сумму хранить, а не цену.
А "0 шт. на сумму 10 рублей" - можно разрешить, это тоже,
что и курсовая разница. Может иногда возникать и штатно...
...
Рейтинг: 0 / 0
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
    #35748654
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
шПапа Игорь,
Как это не хранить количества? А если 100 шт. по 1 коп. - будет 100 квантов?

Здравствуйте!

Минимально оперируемые кванты (в контексте моего сообщения) - это не 1 шт.

Это может быть и кг, и тонна, и литр, и т.п.

Смысл в том, чтобы выбрать наименьшую единицу измерения количества/объема.

Если у вас угольная шахта. Добываете в сутки 50 000 тыс.тонн. Какой "квант" выберете.

Я - тонну.

А если вы ювелир. Квантик получается другой. :-)
...
Рейтинг: 0 / 0
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
    #35748667
ш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ш
Гость
Папа Игорь,
согласен.
Но с формальной точки зрения: как не хранить количества?
Если квант = т (в Вашем примере), то 50000 записей вместо одной?
...
Рейтинг: 0 / 0
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
    #35748806
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ш...Если квант = т (в Вашем примере), то 50000 записей вместо одной?

А что мешает? :-)

Если бы Вы знали насколько при этом упрощаются некоторые учетные задачи.

Или мы нарушаем какие-либо теоритические постулаты?

Просто производим декомпозицию до необходимого нам уровня.

Мы уже удалились от темы ветки. Давайте закруглятся. Согласны?

Успехов.
...
Рейтинг: 0 / 0
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
    #35749457
KOT MATPOCKuH
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ш, Папа Игорь
Но с формальной точки зрения: как не хранить количества?
Если квант = т (в Вашем примере), то 50000 записей вместо одной?
В некоторых задачах количество не нужно.
Например, та же добыча: если добываете абстрактные тонны, то зачем количество?
Другой вопрос, что этот уголь вы кладете в вагоны, тогда имеет смысл кроме веса еще и учитывать вагоны.
Другими словами нужно учитывать те объекты, за которыми следим!
Назвать их можно как угодно. Наиболее частые названия: партия, субпартия, либо конкретно: пачка, бочка, багон, штучка...

В БД можно сделать любую разбивку вплоть до милиграм (для добычи угля), но потом с ней будут (или не будут?) работать люди. Как вы сможете учесть от которой тонны угля не досчитались? Начнете говорить про ФИФО-ЛИФО - зачем тогда вообще такая детализация, если она полностью нивелируется кодом? У меня один ответ - чтобы программисту было чем заняться, другого смысла не вижу.

Все ИМХО, ничего личного к собеседникам ;)
...
Рейтинг: 0 / 0
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
    #35749485
ш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ш
Гость
KOT MATPOCKuH,
можете открыть новую тему "Кванты вместо натуральных измерителей".
Тема то интересная, но у меня мозги не варят, как это осуществить...
...
Рейтинг: 0 / 0
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
    #35749649
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ш...Кванты вместо натуральных измерителей...

Натуральные числа - знаю.

Натуральные измерители - не знаю.

Идея проста, как ...

Вы делаете декомпозицию данных до такого уровня при котором все множество
этих данных является однородным (в контексте задачи). SQL хорошо работает с множествами.

Масштаб хранимых единиц измерения выбирается такой, что верно следующее:
одна запись равна одной единице измерения.

Сравните:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
 1 ). delete top  5  
    from inv 
    where id =  1 
...

 2 ). update inv 
     set qty = qty -  5  
     where id =  1 


В первом случае операция над множеством, во втором - модификация атрибута.
...
Рейтинг: 0 / 0
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
    #35749660
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Папа Игорь...В первом случае операция над множеством, во втором - модификация атрибута.

Возможно мой подход уже старомоден. :-)

Но я привык хранить информацию в БД в виде записей. И изменять ее (информацию)
работая с записями. А модифицировать атрибуты только для исправления ошибок.
...
Рейтинг: 0 / 0
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
    #35749748
ш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ш
Гость
Папа Игорь, благодарю!

Не знаю откуда, но у меня засело в голове, что:
Сумма (руб/валюта), Кол-во - это "Измерители",
а "41","Петров","Носки" - это значения, координаты точки
в "пространстве хоз.операций", где Оси или "Измерения" - это
"Синт.счет", "МОЛ", "ТМЦ" и др...
А как правильно говорить?

При вводе партии (3 шт. на сумму 1 руб.) получаем три записи в таблице.
Эти записи и являются мин.квантом в вашей БД или точкой в пр-ве. Так?
Можете дать типовой состав этой точки (схему таблицы партий)?
...
Рейтинг: 0 / 0
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
    #35750839
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ш...При вводе партии (3 шт. на сумму 1 руб.) получаем три записи в таблице.
Эти записи и являются мин.квантом в вашей БД или точкой в пр-ве. Так?
Можете дать типовой состав этой точки (схему таблицы партий)?

Здравствуйте!

Не отвечая именно на этот Ваш вопрос, постараюсь упростить (без потери качества).

Термин «квант» использовал потому, что , имхо, он более подходит для того,
что мы имеем ввиду, говоря об «атомарности данных». Не в терминах дело.
Дело в соблюдении принципа «атомарности данных».

В учебной литературе, освещая вопросы нормализации, часто приводят пример с телефонными номерами. В одном поле таблицы хранится несколько номеров телефонов: "555-4124; 555-7852…"

Плохо это? Говорят, что плохо. А почему?

Не будем рассуждать о сложности модификации, поиска и т.п. Рассмотрим ИСПОЛЬЗОВАНИЕ.

Практически во всех случаях использования мы будем оперировать ЧАСТЬЮ значения этого поля.
Тогда зачем их хранить вместе. Давайте разобьем это значение на используемые порции - кванты в моей терминологии.
Если номер всегда используется для звонков, то будем хранить полные номера, а если нам требуется делать анализ по телефонным узлам, то квантование продолжим дальше.

Так и с количеством (в нашем примере). Если значение "3 шт" мы ВСЕГДА будем использовать как "3 шт.", то и хранить надо в таком виде.
Но если возможен вариант использования ЧАСТИ значения поля (например - "1 шт."), то и хранить в БД надо эти ЧАСТИ.

Мой подход к нормализации следующий: нормализую полностью при проектировании – денормализую (по разным причинам) при реализации.
...
Рейтинг: 0 / 0
Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
    #35751391
ш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ш
Гость
Папа Игорь!
Идея ваша уже раньше была понятна, но развернутое изложение еще
усугубило это понимание, спасибо. Будем знать и применять, когда уместно будет.

Вопросы были "по касательной".
1) Пространство, Оси, Точки, Значения. Эти термины м.б. и применимы к учету,
но общеприняты ли? Скорее нет. Вы поправили меня в терминах, вот я и
попробовал выяснить попутно, какие правильные слова следует употреблять.
2) Хранение квантов можно по разному устроить. Видимо в таблице "Партии".
Вот я и хотел убедиться (проверив состав записи), что верно догадался...
...
Рейтинг: 0 / 0
24 сообщений из 99, страница 4 из 4
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Поставшики могут быть потребителями и наоборот. Как правильно задать схему данных?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]