powered by simpleCommunicator - 2.0.48     © 2025 Programmizd 02
Форумы / Microsoft Access [игнор отключен] [закрыт для гостей] / Основы проектирования складской БД (v. 2)
25 сообщений из 138, страница 3 из 6
Основы проектирования складской БД (v. 2)
    #38118999
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Shark2слова про партии, без них склад мне не очень понятен. Потому что на реальном складе обычно интересно, с какого прихода товар мы продаем. Ну и выкидывать ненужные "закрытые" партии из расчетов тоже приятно, можно быстрее посчитать остатки

Все документы одинаковы, но некоторые документы одинаковее других. А именно приходные. Партиеобразующие. Если пытатся считать по партиям, то таблички получаются примерно такие

Док- номер, дата, Откуда, Куда, Тип Документа
ДокДет Ссылка на док,ссыдка на Партия, количество, Цена
Партия- Товар, НДС, Таможенная и реестровая всякая фигня
Товар- Наименование

Осталось удостовериться, что заложенная в программу логику соблюдается на складе, и там берут не какую попало коробку, а именно из нужной партии.
...
Рейтинг: 0 / 0
Основы проектирования складской БД (v. 2)
    #38119977
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Geo

кстати:

авторP.S. Вариант 4, я, вероятно, на досуге разделю на 2 подварианта. Когда хранятся только "текущие остатки" - "Отдельный справочник", как пишет "SangYong", и когда в процессе работы создаются промежуточные остатки. Всё-таки отличий между ними довольно много.

Отличий между ними настолько существенны, что требуют этого - выноса текущих остатков в отдельный справочник - не делать вне точно определенного контекста.
Пальцев на асфальте три.

1) "текущие остатки" - нечто, завязанное на понятие "сейчас".
Для кладовщика на конкретном складе - "сейчас" - вменяемо определяемое понятие - гляди на часы и оглядывайся по сторонам на полки. То что видишь, то и есть сейчас.
Для "продавцов", "плановиков", "бухгалтеров" ничего близко похожего на поняте "сейчас" нет. Все что угодно - вроде учетного периода, дня, квартала - есть, а "сейчас" - нет.

2) Второй палец складывается, методом применения аналогии, так:
остатки ты рожаешь как способ развития модели задачи.
Пойнт здесь такой - пока никто не сказал - "хочу неотрицательные остатки" - остатки всего лишь "денормализация" - т.е. твоя личная фантазия про производительность системы.

Но, внезапно, сразу после заявления хотелки, остатки из "денормализации" превращаются в ресурс - обязательную содержательную часть модели, обремененную алгоритмической поддержкой заявленного бизнес-требования.

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

3) Если поняте "сейчас" оказывается хорошо и прозрачно определено для автоматизируемого бизнеса, то моя гипотеза состоит в том, что понятие "таблица остатков", отличных от "сейчас" становится, с высокой вероятностью, излишеством, желательным к удалению с целью упрощения поддерживаюх процедур.





Как-то так.
...
Рейтинг: 0 / 0
Основы проектирования складской БД (v. 2)
    #38120080
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
booby,

"сейчас" = /select Max(date) from совокупность проведенных документов/
Сурово ;)
...
Рейтинг: 0 / 0
Основы проектирования складской БД (v. 2)
    #38120177
Фотография Geo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
booby"текущие остатки" - нечто, завязанное на понятие "сейчас".
Для кладовщика на конкретном складе - "сейчас" - вменяемо определяемое понятие - гляди на часы и оглядывайся по сторонам на
Для "продавцов", "плановиков", "бухгалтеров" ничего близко похожего на поняте "сейчас" нет. Все что угодно - вроде учетного периода, дня, квартала - есть, а "сейчас" - нет.Я не против.

booby<...> развития модели задачи <...> Пойнт здесь такой <...> содержательную часть модели, обремененную алгоритмической поддержкой заявленного бизнес-требования. <...> специальный ресурс под который <...> нет вменяемых бизнес-требованийи т.д., и т.п. Уважаемый Booby. Есть ли у вас силы и время превратить описанные мною, цитирую: "несколько вариантов структуры складской БД" в законченную и вменяемую (читай, понятную и годную для публикации в FAQ) статью, необремененную россыпью красивых и длинных слов, или со словами, вынесенными в четкие и понятные определения? Если да, я с удовольствием помогу в оформлении и редактировании. Если нет, освободите меня, пожалуйста, от гипотетических споров ради споров.

авторпонятие "таблица остатков", отличных от "сейчас" становится, с высокой вероятностью, излишеством, желательным к удалению с целью упрощения поддерживаюх процедур.Да ради бога. Набросайте годную и простую структуру складской бд, и приведите ее в качестве альтернативы. Уверен, ее с интересом обсудят, возможно укажут и на её плюсы и минусы. Или только на плюсы.

Как-то так, ага. )
...
Рейтинг: 0 / 0
Основы проектирования складской БД (v. 2)
    #38120195
Фотография Geo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЗЫ.

авторP.S. Вариант 4, я, вероятно, на досуге разделю на 2 подварианта. Когда хранятся только "текущие остатки" - "Отдельный справочник", как пишет "SangYong", и когда в процессе работы создаются промежуточные остатки. Всё-таки отличий между ними довольно много. Разнес уже, кстати. Вчера еще. И еще пару штрихов cделал, по мотивам увиденных замечаний
...
Рейтинг: 0 / 0
Основы проектирования складской БД (v. 2)
    #38120234
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Geo
Не понимаю я в складах ничего, и не знаю о них даже приблизительно.
Поэтому схему "набросать" не могу.

Ладно, раз мне нельзя задавать вопросы на понимание и высказывать соображения, то и Вам не болеть.
...
Рейтинг: 0 / 0
Основы проектирования складской БД (v. 2)
    #38120257
Фотография Geo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
boobyЛадно, раз мне нельзя задавать вопросы
Ах вот оно что... Я просто за оборотами "ты рожаешь" и "твоя личная фантазия" не разглядел знаков вопроса.
Тогда, раз
boobyмоя гипотеза состоит в том, что понятие "таблица остатков", отличных от "сейчас" становится, с высокой вероятностью, излишеством, желательным к удалению с целью упрощения поддерживаюх процедур, то докладываю: описание этой гипотезы более-менее подходит под обновленный "вариант 4" стартового поста. И в нем же написано, для чего вводится следующий вариант. Собственно, протестировать, на каком количестве записей на железе выбранной могучести вариант 4 начнет тормозить, очень легко. Дальше "пальцы складываются" на калькуляторе, и решается, надо ли ускорять расчеты в конкретном выбранном случае в ущерб простоте реализации, или не надо. Я по мере сил пытался это донести.
...
Рейтинг: 0 / 0
Основы проектирования складской БД (v. 2)
    #38120391
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Geo, за труд всегда надо быть благодарным, поэтому спасибо Вам за него.

Теперь мои пять копеек и, поверьте, я только из хороших побуждений.

Когда создаешь систему учета в 1С, то ВЫНУЖДЕН использовать ее механизмы, идеалогию и приемы, но зачем тащить это в другую среду, которая позволяет сделать это и не так, и лучше, и быстрее.

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

- Человек, шапка пять штука возьми, да?
- Человек, шапка два штука дай сейчас.

Сколько там у нас на складе: 5-2=3.

Вот и достигнута ОСНОВНАЯ цель "Складской БД". Как это сделать "в табличном виде" смешно даже разжевывать.

Идем дальше. Теперь мы расширяем функциональность нашей "Складской БД". Хотим видеть поступление и убыль в разрезе "поставщиков - покупателей". Минимально-оптимальной показала себя схема (Люди, Организации) -> Контракты.
Никаких иерархий и всякой этой фигни от 1С. Зачем иерархия в Организациях или Людях? Что ею достигается?
Я понимаю, что иерархия нужна при сборках, изготовлении и т.п., но на складе этого ничего не происходит.
Да и иерархия складов, как-то дико смотрится. Это типа маленький склад, находится внутри большого, или они связаны "родственными" связами. Есль склады, на них работают МОЛы, отношения могут быть и 1-1, и 1-М... Выбрать, сгруппировать труда не составляет и в живую, и автоматом (по нужным хранимым критериям).

Теперь вводим операцию "Ревизия". По ее результатам может быль и "+" и "-" по каким-то ТМЦ. Появляется таблица причин отклонений.

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

Ну вот в ОСНОВНОМ мы наладили натуральный учет ТМЦ.
Имеем:
1). остатки в разрезе МОЛов, складов, мест хранения
2). анализ движения в разрезе поставщиков - покупателей
3). анализ потерь и доходов по результатам ревизий.

Работу "Складской БД" в денежном выражении дописать уже не составляет труда.
...
Рейтинг: 0 / 0
Основы проектирования складской БД (v. 2)
    #38120408
Фотография Geo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Папа ИгорьGeo, за труд всегда надо быть благодарным, поэтому спасибо Вам за него.На здоровье )

Папа Игорь...ОСНОВНАЯ цель "Складской БД". Как это сделать "в табличном виде" смешно даже разжевывать.

Идем дальше. Теперь мы расширяем функциональность нашей "Складской БД". Хотим видеть поступление и убыль в разрезе "поставщиков - покупателей". Минимально-оптимальной показала себя схема (Люди, Организации) -> Контракты.Добавляем поля Люди, Организации, Контракты и другие, "в разрезе которых" планируется делать отчеты в таблицу Doc, хоть в вариант 1, и ничего не напоминает нам об 1С :)

Папа ИгорьНикаких иерархий и всякой этой фигни от 1С. Зачем иерархия в Организациях или Людях? Что ею достигается?
Я понимаю, что иерархия нужна при сборках, изготовлении и т.п., но на складе этого ничего не происходит.
Да и иерархия складов, как-то дико смотрится. Это типа маленький склад, находится внутри большого, или они связаны "родственными" связами. Есль склады, на них работают МОЛы, отношения могут быть и 1-1, и 1-М... Выбрать, сгруппировать труда не составляет и в живую, и автоматом (по нужным хранимым критериям).Если немного абстрагироваться от уже имеющегося опыта автоматизации, то вполне можно предположить, зачем нужна иерархия в организациях (ведь не все организации торгуют оптом двумя сортами пива, у производственников, например, сотни поставщиков - это нормальное явление), в людях (если в организации работает больше десятка сотрудников), в складах (ведь некоторые склады хотят учета по местам хранения, внутри мест хранения по ячейкам, и т.д.)

Папа ИгорьНу вот в ОСНОВНОМ мы наладили натуральный учет ТМЦ.
Имеем:
1). остатки в разрезе МОЛов, складов, мест хранения
2). анализ движения в разрезе поставщиков - покупателей
3). анализ потерь и доходов по результатам ревизий.

Работу "Складской БД" в денежном выражении дописать уже не составляет труда.:)
...
Рейтинг: 0 / 0
Основы проектирования складской БД (v. 2)
    #38120433
qwerty112
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Папа ИгорьНачнем с простого. Какова самая главная цель "Складской БД"? Обеспечить учет ТМЦ. Поступление-убыль-остаток. Остаток это отчет. Для его получение надо безошибочно (ах, если бы это было возможно) учитывать поступление и убыль. До смешного просто:

- Человек, шапка пять штука возьми, да?
- Человек, шапка два штука дай сейчас.

Сколько там у нас на складе: 5-2=3.

Вот и достигнута ОСНОВНАЯ цель "Складской БД". Как это сделать "в табличном виде" смешно даже разжевывать.

дык, вы покажите КАК , а потом, вместе посмеёмся :)
чёта, я, пока, не понял за что вы "агитируете" ? "вести" всё в одной табличке ("сделать "в табличном виде" ) ? или, не побоюсь этого слова, - в Экселе ?

Папа ИгорьИдем дальше. Теперь мы расширяем функциональность нашей "Складской БД". Хотим видеть поступление и убыль в разрезе "поставщиков - покупателей". Минимально-оптимальной показала себя схема (Люди, Организации) -> Контракты.

что есть "Контракты" ?
это табличка такая ? - с какими полями ?
несколько табличек ? - с какими полями "несколько табличек" ?

... и в чём "идеологическое" отличие этого вашего "контракт" от "документ" ? или совсем разных "понятий" вещии ?
вообщем, - "подробностей давай !" (с)

Папа ИгорьНикаких иерархий и всякой этой фигни от 1С. Зачем иерархия в Организациях или Людях? Что ею достигается?
Я понимаю, что иерархия нужна при сборках, изготовлении и т.п., но на складе этого ничего не происходит.
Да и иерархия складов, как-то дико смотрится. Это типа маленький склад, находится внутри большого, или они связаны "родственными" связами. Есль склады, на них работают МОЛы, отношения могут быть и 1-1, и 1-М... Выбрать, сгруппировать труда не составляет и в живую, и автоматом (по нужным хранимым критериям).

... даа, вроде бы как, никто особо на иерархию "не напирал", включая автора ...
надо - вводим, не надо - не вводим ...

Папа ИгорьТеперь вводим операцию "Ревизия". По ее результатам может быль и "+" и "-" по каким-то ТМЦ. Появляется таблица причин отклонений.

что такое "операция "Ревизия" ?
это обработка какая-то, которая время от времени запускается, или что ?
...
Рейтинг: 0 / 0
Основы проектирования складской БД (v. 2)
    #38120436
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Geo, иерархия это всеже какая-то связь: вхождение, подчинение...

Если не уходить от темы топика " Основы проектирования складской БД" никакой иерархии быть не должно.

На мой взгляд, коллега, Вы вместо основ пытаетесь построить базу какого-то абстрактного предприятия с упрощениями, которые Вам кажутся не важными.

Тогда уж лучше взять конкретную фирму (небольшую) и на ее примере соорудить уже базу, но не ОСНОВУ, а со всеми Doc-ами, суммами и даже проводками. Проводки, кстати это уже чистая 1С. Проводки нужны для учета/отчетности, идут от бумажного учета и сейчас не нужны для хранения в базе. На выходе (в отчетах) они появляются, а хранить их не надо,
...
Рейтинг: 0 / 0
Основы проектирования складской БД (v. 2)
    #38120459
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qwerty112дык, вы покажите КАК , а потом, вместе посмеёмся :)
чёта, я, пока, не понял за что вы "агитируете" ? "вести" всё в одной табличке ("сделать "в табличном виде" ) ? или, не побоюсь этого слова, - в Экселе ?
Показать-то, что надо? Как таблицы проектировать или их структуру? Для " Основы складской БД " надо 10-12 таблиц:
1. Поступление (2)
2. Выбытие (2)
3. Оклонения (2)
4. Причины отклонения
5. Люди
6. Склады
7. Связка Люди-Склады = МОЛы
8. Организации
9. Контракты.

qwerty112что есть "Контракты" ?
это табличка такая ? - с какими полями ?
Храним людей, храним Организации. Люди (в нашем случае) могут выступать как МОЛы, как поставщики, как потребители. Для учета роли МОЛов служит таблица связи Люди-Склады. Для учета других ролей служит связь Люди-Контракты-(Поступление или Выбытие). Аналогично Организации - Контракты - (Поступления или Выбытие).

qwerty112... и в чём "идеологическое" отличие этого вашего "контракт" от "документ" ? или совсем разных "понятий" вещии ?
вообщем, - "подробностей давай !" (с)
ну это я уже объяснил.

qwerty112что такое "операция "Ревизия" ?
это обработка какая-то, которая время от времени запускается, или что ?
Назовите её "Выявление человеческого фактора и деятельности гремлинов".
Запускается приказом руководителя. В некоторых странах имеет обязательных характер. :-)

Для пояснения основ складской БД этих таблиц вполне хватает.
...
Рейтинг: 0 / 0
Основы проектирования складской БД (v. 2)
    #38120489
qwerty112
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Папа Игорьqwerty112что есть "Контракты" ?
это табличка такая ? - с какими полями ?
Храним людей, храним Организации. Люди (в нашем случае) могут выступать как МОЛы, как поставщики, как потребители. Для учета роли МОЛов служит таблица связи Люди-Склады. Для учета других ролей служит связь Люди-Контракты-(Поступление или Выбытие). Аналогично Организации - Контракты - (Поступления или Выбытие).

qwerty112... и в чём "идеологическое" отличие этого вашего "контракт" от "документ" ? или совсем разных "понятий" вещии ?
вообщем, - "подробностей давай !" (с)
ну это я уже объяснил.
вы на простые вопросы можете отвечать ?
я подсвечу
qwerty112что есть "Контракты" ?
это табличка такая ? - с какими полями ?
сущность "Контракт" - описать словами сможете ?
если не сможете - меня устроит список полей/подч.таблиц этой таблицы/структуры

зы
на 1-ую и посл.мою "квоту", отвечал, имхо инопланетянин
настолько не понимать, что тебя спрашивают, человек не может ...
...
Рейтинг: 0 / 0
Основы проектирования складской БД (v. 2)
    #38120515
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qwerty112на 1-ую и посл.мою "квоту", отвечал, имхо инопланетянин
настолько не понимать, что тебя спрашивают, человек не может ...

Настолько не понимать простые слова это тоже уметь надо. А на Ваш вопрос про контракты (таблица это или что другое) ответ был ясным:

Люди - Контракты - (Поступление или Выбытие)...
Организации - Контракты - (Поступление или Выбытие)...

Из этого непонятно ЧТО есть Контракты?

Тогда поясню: ЭТО ТАБЛИЦА для связи. Минимально два поля Ключ (обычный счетчик) и Объект (гуид). В поле Объект хратится ключ Людя или Организации. Для минимального анализа это надо. Другие поля (дата, вид, условия выполнение и т.п.) добавляются с расширением функциональности. Но это уже выходит за рамки ОСНОВ.
...
Рейтинг: 0 / 0
Основы проектирования складской БД (v. 2)
    #38120540
qwerty112
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Папа ИгорьИз этого непонятно ЧТО есть Контракты?

Тогда поясню: ЭТО ТАБЛИЦА для связи. Минимально два поля Ключ (обычный счетчик) и Объект (гуид).
"кено" с вами, прям :))
что б, что-то связывать - как минимум два поля понадобится (помимо "(обычный счетчик)")
а у вас - одно ...

и, таки, что с чем связывает ?
ЛюдУ / Организацию с "Поступление" или "Выбытие" , если я правильно понял, так ?

тогда вопрос - тот же

что есть "Поступление" ("Выбытие") ?
это табличка такая ? - с какими полями ?
Папа ИгорьНастолько не понимать простые слова это тоже уметь надо.
давайте я поясню кое-что по "пониманию":
- появляется некто, с такой вводной - "чо вы, мол, с этой 1с-вской "парадигмой" маетесь ? проще нужно быть ! вона у меня - гля как !"

вот я и предлагаю вам, описать эту вашу "вона у меня",
и хотелось, что бы это действительно оказалась НЕ 1С

а на данный момент, это ваше "Контракты" - это "шапка" документа и ничего более, - чётко как 1С завещала
Папа ИгорьМинимально два поля Ключ (обычный счетчик) и Объект (гуид). В поле Объект хратится ключ Людя или Организации. Для минимального анализа это надо. Другие поля (дата, вид, условия выполнение и т.п.)

не сомневаюсь, что эти вот "Поступление" ("Выбытие") - окажутся "строками" документа,
...аа назвать - и горшком можно ...
...
Рейтинг: 0 / 0
Основы проектирования складской БД (v. 2)
    #38120568
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qwerty112, как бы так помягче. :-)

Контрагентами по бизнесу могут выступать как люди так и организации. Держать их в таблице контагенты с полями для разных сущностей есть неправильно. Это понятно и начинающим.

В жизни если Вы что-то покупаете в конторе даже без заключения письменного договора считается, что договор был заключен. Это оговаривается в Гражданском кодексе. Таблица Контракт и служит для хранения этих договоров. Зачем? Ну подумайте на досуге.
Да, Ва можете провести анализ покупок-продаж на основе таблицы контрагенты, только это ограничит Вас в дальнейшем. Да и избыточной инфы наплодите (денормализуете без всякого выигрыша).

Полей в указанных таблицах вполне хватает для организации связей.
...
Рейтинг: 0 / 0
Основы проектирования складской БД (v. 2)
    #38120599
qwerty112
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Папа Игорьqwerty112, как бы так помягче. :-)

Контрагентами по бизнесу могут выступать как люди так и организации. Держать их в таблице контагенты с полями для разных сущностей есть неправильно. Это понятно и начинающим.

про "полями для разных сущностей" - само собой,
а вот начало фразы - это очень спорно

но вас спрашивали - совершенно не об этом,
какого вы "сваливаетесь" на какие-то частности ?

считайте, что вы работаете - только с организациями !
вот вам схема (самая простая)


сделанная "по 1с-вски"
покажите свой аналог этой схемы НЕ "по 1с-вски"

Папа ИгорьКогда создаешь систему учета в 1С, то ВЫНУЖДЕН использовать ее механизмы, идеалогию и приемы, но зачем тащить это в другую среду, которая позволяет сделать это и не так, и лучше, и быстрее.
вот эту свою "петицию", проиллюстрируйте чем-нибудь, отличным от "охов / ахов и закатывания глазок"

---

Папа ИгорьВ жизни если Вы что-то покупаете в конторе даже без заключения письменного договора считается, что договор был заключен. Это оговаривается в Гражданском кодексе. Таблица Контракт и служит для хранения этих договоров. Зачем? Ну подумайте на досуге.
Да, Ва можете провести анализ покупок-продаж на основе таблицы контрагенты, только это ограничит Вас в дальнейшем. Да и избыточной инфы наплодите (денормализуете без всякого выигрыша).
к чему была написанна вся эта херь, я не понимаю

Папа ИгорьПолей в указанных таблицах вполне хватает для организации связей.

только очень наивный человек может называть таб.Contract, в этой схеме - "таблицей связи"
почему ? Ну подумайте на досуге.
...
Рейтинг: 0 / 0
Основы проектирования складской БД (v. 2)
    #38120615
Фотография Папа Игорь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qwerty112, я не буду упрощать до "работы только с организациями". Я нарисую Вам ОСНОВЫ складской БД. Сегодня уже нет. Завтра - может вечером.
Об 1С сказал в разрезе слов ТС об Операциях и проводках и заточках на Документах.
Даже в складской БД учитывают не документы а бизнесоперации, которые должны, а иногда и не должны (на Украине есть понятие упрощенцев) оформляться документами.

И это... только очень наивный человек НЕ назовет Таблицу Contract таблицей связи. И чтобы Вы не утруждали себя на досуге расшифрую.

Эта таблица позволяет СВЯЗАТЬ разные сущности (люди и организации) со сделками не нарушая нормализации и отражает "объективную реальность" данную нам законодательством. Дополнительная функциональность (когда будет необходимость) - это разные условия сделок, сроки исполнения и даже налогообложение.
...
Рейтинг: 0 / 0
Основы проектирования складской БД (v. 2)
    #38120619
qwerty112
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Папа Игорьqwerty112, я не буду упрощать до "работы только с организациями". Я нарисую Вам ОСНОВЫ складской БД.
ок, спасибо
мне действительно интересно

зы
ближайшие пару-тройку дней буду ридонли, но как - только, так - сразу ... :)
...
Рейтинг: 0 / 0
Основы проектирования складской БД (v. 2)
    #38120620
полином
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Папа Игорьтолько очень наивный человек НЕ назовет Таблицу Contract таблицей связи.
в университетах преподаются примерно 12 точек зрения и рассматривается примерно 45 мнений по этому вопросу.
они общеизвестны.
...
Рейтинг: 0 / 0
Основы проектирования складской БД (v. 2)
    #38120641
2 GEO
автороборотами "ты рожаешь" и "твоя личная фантазия" не разглядел знаков вопроса
в тех предложениях не было вопросов, поэтому не стояло знаков.

"рожаешь" и "фантазия" в том контексте - слова указатели.
Рожаешь - слово, обозначающее процесс. Использовано для указания на творческий характер процесса проектирования, в результате которого появляется, рождается структура БД. Автор структуры ее родитель в переносном, но полностью аналогичном смысле.

"фантазия" - слово, указывающее на необязательность конструкта, использование которого основано либо просто на личном предпочтении, либо на соображениях, выходящих за пределы минимально достаточных для получения работоспособного прототипа. Таблицы остатков первоначально происходят не столько от минимально необходимой модели предметной области, сколько от соображений обеспечения приемлего времени отклика oltp системы при увеличении объема данных. Поэтому изначально это фантазия.
До тех пор пор пока ...

Использовались обсуждаемые слова как метафоры, а не дисфемизмы.


2 qwerty112
удовлетворите любопытство пожалуйста:
Почему Вам не стыдно отвечать на вопросы, обращенные на Вам?
Потому что Вы не доверяете интеллекту топикстартера?
Или Вас так прет, что Вы просто на эту тему не задумываетесь?
...
Рейтинг: 0 / 0
Основы проектирования складской БД (v. 2)
    #38120697
ZezaM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
сосед акцессник,


2 qwerty112
удовлетворите любопытство пожалуйста:
Почему Вам не стыдно отвечать на вопросы, обращенные на Вам?
Потому что Вы не доверяете интеллекту топикстартера?
Или Вас так прет, что Вы просто на эту тему не задумываетесь?

грубо, имхо...

лично мне все содержательные ответы - интересны,
независимо от - кому вопрос, кто ответил и тд...
и если не важно чей ответ мне что-то прояснил
ответившему - искренний респект
...
Рейтинг: 0 / 0
Основы проектирования складской БД (v. 2)
    #38120703
t1002
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ZezaMлично мне все содержательные ответы - интересны,
независимо от - кому вопрос, кто ответил и тд...

Но видимо не все поддерживают данную точку зрения.
...
Рейтинг: 0 / 0
Основы проектирования складской БД (v. 2)
    #38120777
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Папа Игорь,

Вы не задумывались, что складская БД оторванная от системы - это ваше воображение? Если используем ее в учетной системе - целью "складской БД" может быть примитивный учет, если в wms - то к "первому плану" и основной цели подходят слегка другие вещи, как то: технологические процесса само собой не без учета ТМЦ, от которого никто никуда не денется.


Папа Игорь Вот и достигнута ОСНОВНАЯ цель "Складской БД". Как это сделать "в табличном виде" смешно даже разжевывать.

Как много уже говорилось в этом топике и как я только сказал, "простая складская БД" может быть в частью сложной системы WMS или просто "самобытного" образования. И в таком случае все 4 варианта становятся на свои места исходя из задач, которые решает автоматизация склада. И само собой, процитированный выше отрывок совершенно теряет смысл, так как в простейшем случае динамические остатки в самом деле разжевывать нечего, но как только неожиданно склад становится учет тмц не только в штуках, но и в весе, как только мы подключаем модуль "снабжение" для анализа динамики остатков, как только у нас появляются "остатки на дату" мы заводит и "остатки на сейчас" и так далее, усложняя и усложняя механизмы в погоне за производительностью. И именно для этих задач были написаны данные примеры, так как я видел фактически все 4 реализации "основ складской БД" на практике и наблюдал всю эволюцию, от примитивного учета ТМЦ, до самописной WMS
...
Рейтинг: 0 / 0
Основы проектирования складской БД (v. 2)
    #38120781
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
t1002ZezaMлично мне все содержательные ответы - интересны,
независимо от - кому вопрос, кто ответил и тд...

Но видимо не все поддерживают данную точку зрения.

Да, воспитание никогда не станет нормой, согласен.
...
Рейтинг: 0 / 0
25 сообщений из 138, страница 3 из 6
Форумы / Microsoft Access [игнор отключен] [закрыт для гостей] / Основы проектирования складской БД (v. 2)
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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