|
|
|
Проектирование БД
|
|||
|---|---|---|---|
|
#18+
Всем привет. Помогите пожалуйста разобраться с некоторыми кусками в моей БД, задача по учебе. Есть задача, полный текст приводить не буду, попробую задать конкретные вопросы. 1. Есть таблица Контрактов, в ней хранится много всего, в том числе ссылки на 1. Плательщика 2. Грузополучателя 3. Клиента - это все разные роли и они по совместительству являются контрагентами. Получился какой-то такой ужас: Честно понимаю что это просто какой-то бред но как иначе это сделать не придумал. Была такая мысль: Но и это не подходит т.к. эти поля плательщик, грузополучатель и тп - обязательны. Скорее всего это ужасные варианты, может быть кто-то опытный сходу скажет как этот кусок сделать по-человечески? 2. Блок поставка (delivery) - счет фактура (Invoice). Условие такое - 1 фактура может закрывать много поставок. При этом фактура может быть как до поставки так и после. Я сделал так, но на деле это мне кажется странным и плохим вариантом. Как сделать это нормально? Опять же надеюсь кто-то из практики подскажет. 3. Последний вопрос просто словесно, если кто-то сможет ответить, после первых двух: если у нас есть КОНТРАКТ, по нему есть ЗАКАЗ, от заказа ПОСТАВКА, все они имеют свой перечень товаров, правильно ли делать для каждой из этих таблиц дополнительную таблицу: КОНТРАКТ_ТОВАРЫ которые потом вести в таблицу ТОВАРЫ или можно как-то иначе? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2015, 14:41 |
|
||
|
Проектирование БД
|
|||
|---|---|---|---|
|
#18+
Последняя картинка не тему, это какой-то старый неправильный огрызок, случайно добавил. Как исправить сообщение не знаю, как понял тут их не меняют. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2015, 14:47 |
|
||
|
Проектирование БД
|
|||
|---|---|---|---|
|
#18+
oddo Честно понимаю что это просто какой-то бред но как иначе это сделать не придумал. Ну не то чтобы совсем бред - но некоторая избыточность. Вы уверены, что Вам нужны отдельные таблицы Payer, Customer и т.п. - почему бы не сделать ссылки прямо на Counteragent? Ваш вариант имеет смысл, если некий контрагент может быть, скажем, плательщиком но ни в коем случае не может быть грузополучателем - тогда да, дополнительная типизация оправданна. Но даже в этом случае я отказался бы от отдельных ID в этих таблицах и везде сделал бы первичным ключом IDCounteragent ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2015, 16:44 |
|
||
|
Проектирование БД
|
|||
|---|---|---|---|
|
#18+
А напрямую это как? Я и хотел сделать напрямую, но не понял как связать поля плательщик, заказчик, и тд с таблицей контрагентов и поэтому начал изобретать велосипед. Если я просто сделаю Counteragent 1 -----> n Contract то в итоге у меня в Contract будет 1 внешний ключ, а надо 4 поля. Мб я что-то очевидное не понимаю, если можно найдите пример того что вы имеете ввиду или просто опишите связь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2015, 17:32 |
|
||
|
Проектирование БД
|
|||
|---|---|---|---|
|
#18+
Вы сделаете 4 связи 1 CounterAgent -> n Contract. У таблицы A на таблицу B может быть множество внешних ключей. Если Ваше средство проектирования такого не позволяет - вносите ограничения foreign key в скрипт создания таблицы вручную. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2015, 17:45 |
|
||
|
Проектирование БД
|
|||
|---|---|---|---|
|
#18+
> Есть задача, полный текст приводить не буду Напрасно. В таком случае вы вряд ли получите хорошие ответы на ваши вопросы. > 1. Плательщика 2. Грузополучателя 3. Клиента - это все разные роли и они по совместительству являются контрагентами. Рассмотрите вариант, при котором необходимость дополнительных таблиц становится явной. Скажем, лавка имеет несколько филиалов, каждый из которых может выступать грузополучателем. > правильно ли делать для каждой из этих таблиц дополнительную таблицу: КОНТРАКТ_ТОВАРЫ Зависит от того, как вы определили контракт. Вообще - да. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2015, 19:38 |
|
||
|
Проектирование БД
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Есть задача, полный текст приводить не буду Напрасно. В таком случае вы вряд ли получите хорошие ответы на ваши вопросы. > 1. Плательщика 2. Грузополучателя 3. Клиента - это все разные роли и они по совместительству являются контрагентами. Рассмотрите вариант, при котором необходимость дополнительных таблиц становится явной. Скажем, лавка имеет несколько филиалов, каждый из которых может выступать грузополучателем. > правильно ли делать для каждой из этих таблиц дополнительную таблицу: КОНТРАКТ_ТОВАРЫ Зависит от того, как вы определили контракт. Вообще - да.ну рассмотрел и чож там интереснага ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2015, 15:36 |
|
||
|
Проектирование БД
|
|||
|---|---|---|---|
|
#18+
Спасибо за советы, разобрался как соединить контракты и контрагенты, вроде. Сейчас пока нет времени на эту БД, как доберусь апну тему еще раз. Там по этой базе завал, явно не мой уровень, но доделать хочется. А пока - может кто-то подскажет насчет второго вопроса? Какая обычно в базах архитектура у этого куска - ПОСТАВКА + СЧЕТ-ФАКТУРА? В интернетах нахожу примеры только простейших баз. Если у кого-то есть запасенная ссылка на какую-нибудь открытую достаточно солидную ERP-базу, скиньте пожалуйста, я бы думаю много каких мыслей мог бы из нее извлечь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2015, 03:18 |
|
||
|
Проектирование БД
|
|||
|---|---|---|---|
|
#18+
1. Есть таблица Контрактов, в ней хранится много всего, в том числе ссылки на 1. Плательщика 2. Грузополучателя 3. Клиента - это все разные роли и они по совместительству являются контрагентами. Получился какой-то такой ужас: в чем бред? нормальная структура. правда, можно без промежуточных таблиц ролей, но тогда не будет контроля допустимости контингента в роли. у скажет как этот кусок сделать по-человечески? я еще потом погляжу... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2015, 06:59 |
|
||
|
Проектирование БД
|
|||
|---|---|---|---|
|
#18+
> Какая обычно в базах архитектура у этого куска - ПОСТАВКА + СЧЕТ-ФАКТУРА? Обычно - кривая. Не нужно ориентироваться на существующие реализации: вы будете копировать чужие ошибки. Счёт-фактура - способ учёта НДС (в нынешнем совке), любая другая нагрузка - факультативна. Для того, чтобы понимать, что вы проектируете, вам нужно иметь хотя бы поверхностное представление о налогах и деловой практике. Это совсем не учебная задача. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2015, 11:18 |
|
||
|
Проектирование БД
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинВы сделаете 4 связи 1 CounterAgent -> n Contract. У таблицы A на таблицу B может быть множество внешних ключей. Если Ваше средство проектирования такого не позволяет - вносите ограничения foreign key в скрипт создания таблицы вручную.Кот МатроскинЕсли Ваше средство проектирования такого не позволяет - вносите ограничения foreign key в скрипт создания таблицы вручную.Я думаю, это любое средство проектирования позволяет. Где то нужно поглядеть, как делать связи "разными полями". Скорее, не делать скрипт вручную, а настроить каждую линию FK отдельно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2015, 00:33 |
|
||
|
Проектирование БД
|
|||
|---|---|---|---|
|
#18+
oddo, по 1. на каждый заказ отдельный договор подписывается? по-моему подписываются обобщенные условия и взаимные обязательства, а на кого везется и уж тем более получатель ("там постучите в ворота, спросите Васю") - детали конкретного заказа. юрист и печати тут вроде не нужны. плательщики обычно являются дочерними к клиенту, на схеме нарисовано почти это (на самом деле просто связь протянута за кастомерами визуально; полосочки на схеме надо разводить. так нельзя). получатели скорее всего тоже должны быть дочерними к кому-то (скорее всего кастомерам) - более для удобства (находить из ограниченного перечня; хотя можно и через старые заказы, но это немножко другое) не уверен что получатели нужны в перечне контрагентов. если только "для повышения уровня абстракции". как вариант - вполне возможно. invoicerecipient - это скорее вы свои конторы на которые можете возить (на свой контракт) можете так пометить, а относительно клиента - да кого скажет, того и поставите. не уверен что такой жесткий справочник нужен. с другой стороны, если в контрагентов будут свалены вообще все (в т.ч. те, с которыми вы _дел_ не имеете, которые нужны только как название и перечень контактов), то по таким табличкам придется разносить абсолютно все возникающие типы контрагентов. это нормально, главное правильно связи расставить. с чем сложнее работать - вопрос отдельный. как вариант, на payer, customer и т.д. сделать вьюхи с джойнами на контрагента или денормализовать и в них хранить: названия и что-то еще основное нужно легко получать, чтобы не мучаться потом в запросах. не отражены собственные конторы. тридцать три ООО и ИП для физиков (фантазирую) - вот они будут возникать "с одной стороны" в контракте, а не вбитый фиксированный текст. свои конторы также могут друг для друга быть контрагентами и клиентами. по 3. опять же, не уверен что товары имеют отношение к договору. к заказу - да. для кого "для каждой из них" - не понял. от заказа->груз(1..n) от груза можно раскручивать в сторону номенклатуры или транспорта грузополучатель и грузоотправитель могут быть (в зависимости от того как работаете) разные, отдельные для каждого груза, т.е. даже не на уровне заказа определенные. доставляется скорее всего каждый отдельный груз, а не заказ. (статус плоскогубцев - в офисе, статус стремянки - ожидается) если разные грузополучатели, то ехать могут и в одной машине, но сначала будет доставлено одно, только потом другое. по 2. сделайте инвойс с привязкой к контракту или заказу, как станет понятнее - отрефакторите. про некую "поставку" и инвойс не очень понял. кто эти связи будет проставлять? -- расписывайте сценарии по сущностям. угадать всё, сидя в параллельной вселенной не получится. по тому же контракту - уточните у юриста или главного коммерса. заключается ли он каждый раз, если клиент возит 100 заказов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2015, 09:22 |
|
||
|
|

start [/forum/topic.php?fid=32&gotonew=1&tid=1540436]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
151ms |
get topic data: |
11ms |
get first new msg: |
7ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
| others: | 256ms |
| total: | 505ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...