Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование БД / 12 сообщений из 12, страница 1 из 1
22.11.2015, 14:41
    #39110188
oddo
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование БД
Всем привет. Помогите пожалуйста разобраться с некоторыми кусками в моей БД, задача по учебе. Есть задача, полный текст приводить не буду, попробую задать конкретные вопросы.

1. Есть таблица Контрактов, в ней хранится много всего, в том числе ссылки на 1. Плательщика 2. Грузополучателя 3. Клиента - это все разные роли и они по совместительству являются контрагентами. Получился какой-то такой ужас:


Честно понимаю что это просто какой-то бред но как иначе это сделать не придумал. Была такая мысль:



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

2. Блок поставка (delivery) - счет фактура (Invoice). Условие такое - 1 фактура может закрывать много поставок. При этом фактура может быть как до поставки так и после. Я сделал так, но на деле это мне кажется странным и плохим вариантом. Как сделать это нормально? Опять же надеюсь кто-то из практики подскажет.



3. Последний вопрос просто словесно, если кто-то сможет ответить, после первых двух: если у нас есть КОНТРАКТ, по нему есть ЗАКАЗ, от заказа ПОСТАВКА, все они имеют свой перечень товаров, правильно ли делать для каждой из этих таблиц дополнительную таблицу: КОНТРАКТ_ТОВАРЫ которые потом вести в таблицу ТОВАРЫ или можно как-то иначе?
...
Рейтинг: 0 / 0
22.11.2015, 14:47
    #39110198
oddo
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование БД
Последняя картинка не тему, это какой-то старый неправильный огрызок, случайно добавил. Как исправить сообщение не знаю, как понял тут их не меняют.
...
Рейтинг: 0 / 0
22.11.2015, 16:44
    #39110286
Кот Матроскин
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование БД
oddo Честно понимаю что это просто какой-то бред но как иначе это сделать не придумал.
Ну не то чтобы совсем бред - но некоторая избыточность.
Вы уверены, что Вам нужны отдельные таблицы Payer, Customer и т.п. - почему бы не сделать ссылки прямо на Counteragent?
Ваш вариант имеет смысл, если некий контрагент может быть, скажем, плательщиком но ни в коем случае не может быть грузополучателем - тогда да, дополнительная типизация оправданна. Но даже в этом случае я отказался бы от отдельных ID в этих таблицах и везде сделал бы первичным ключом IDCounteragent
...
Рейтинг: 0 / 0
22.11.2015, 17:32
    #39110313
oddo
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование БД
А напрямую это как? Я и хотел сделать напрямую, но не понял как связать поля плательщик, заказчик, и тд с таблицей контрагентов и поэтому начал изобретать велосипед. Если я просто сделаю Counteragent 1 -----> n Contract то в итоге у меня в Contract будет 1 внешний ключ, а надо 4 поля. Мб я что-то очевидное не понимаю, если можно найдите пример того что вы имеете ввиду или просто опишите связь.
...
Рейтинг: 0 / 0
22.11.2015, 17:45
    #39110326
Кот Матроскин
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование БД
Вы сделаете 4 связи 1 CounterAgent -> n Contract. У таблицы A на таблицу B может быть множество внешних ключей. Если Ваше средство проектирования такого не позволяет - вносите ограничения foreign key в скрипт создания таблицы вручную.
...
Рейтинг: 0 / 0
22.11.2015, 19:38
    #39110412
guest_20040621
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование БД
> Есть задача, полный текст приводить не буду

Напрасно. В таком случае вы вряд ли получите хорошие ответы на ваши вопросы.

> 1. Плательщика 2. Грузополучателя 3. Клиента - это все разные роли и они по совместительству являются контрагентами.

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

> правильно ли делать для каждой из этих таблиц дополнительную таблицу: КОНТРАКТ_ТОВАРЫ

Зависит от того, как вы определили контракт. Вообще - да.
...
Рейтинг: 0 / 0
23.11.2015, 15:36
    #39111131
21123
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование БД
guest_20040621> Есть задача, полный текст приводить не буду

Напрасно. В таком случае вы вряд ли получите хорошие ответы на ваши вопросы.

> 1. Плательщика 2. Грузополучателя 3. Клиента - это все разные роли и они по совместительству являются контрагентами.

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

> правильно ли делать для каждой из этих таблиц дополнительную таблицу: КОНТРАКТ_ТОВАРЫ

Зависит от того, как вы определили контракт. Вообще - да.ну рассмотрел


и
чож там интереснага
...
Рейтинг: 0 / 0
24.11.2015, 03:18
    #39111586
oddo
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование БД
Спасибо за советы, разобрался как соединить контракты и контрагенты, вроде.
Сейчас пока нет времени на эту БД, как доберусь апну тему еще раз. Там по этой базе завал, явно не мой уровень, но доделать хочется.

А пока - может кто-то подскажет насчет второго вопроса? Какая обычно в базах архитектура у этого куска - ПОСТАВКА + СЧЕТ-ФАКТУРА? В интернетах нахожу примеры только простейших баз. Если у кого-то есть запасенная ссылка на какую-нибудь открытую достаточно солидную ERP-базу, скиньте пожалуйста, я бы думаю много каких мыслей мог бы из нее извлечь.
...
Рейтинг: 0 / 0
24.11.2015, 06:59
    #39111601
MasterZiv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование БД
1. Есть таблица Контрактов, в ней хранится много всего, в том числе ссылки на 1. Плательщика 2. Грузополучателя 3. Клиента - это все разные роли и они по совместительству являются контрагентами. Получился какой-то такой ужас:



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

у скажет как этот кусок сделать по-человечески?


я еще потом погляжу...
...
Рейтинг: 0 / 0
24.11.2015, 11:18
    #39111850
guest_20040621
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование БД
> Какая обычно в базах архитектура у этого куска - ПОСТАВКА + СЧЕТ-ФАКТУРА?

Обычно - кривая. Не нужно ориентироваться на существующие реализации: вы будете копировать чужие ошибки. Счёт-фактура - способ учёта НДС (в нынешнем совке), любая другая нагрузка - факультативна. Для того, чтобы понимать, что вы проектируете, вам нужно иметь хотя бы поверхностное представление о налогах и деловой практике. Это совсем не учебная задача.
...
Рейтинг: 0 / 0
27.11.2015, 00:33
    #39114514
alexeyvg
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование БД
Кот МатроскинВы сделаете 4 связи 1 CounterAgent -> n Contract. У таблицы A на таблицу B может быть множество внешних ключей. Если Ваше средство проектирования такого не позволяет - вносите ограничения foreign key в скрипт создания таблицы вручную.Кот МатроскинЕсли Ваше средство проектирования такого не позволяет - вносите ограничения foreign key в скрипт создания таблицы вручную.Я думаю, это любое средство проектирования позволяет.
Где то нужно поглядеть, как делать связи "разными полями".
Скорее, не делать скрипт вручную, а настроить каждую линию FK отдельно.
...
Рейтинг: 0 / 0
27.11.2015, 09:22
    #39114604
Проектирование БД
oddo,

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

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

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

invoicerecipient - это скорее вы свои конторы на которые можете возить (на свой контракт) можете так пометить, а относительно клиента - да кого скажет, того и поставите. не уверен что такой жесткий справочник нужен.

с другой стороны, если в контрагентов будут свалены вообще все (в т.ч. те, с которыми вы _дел_ не имеете, которые нужны только как название и перечень контактов), то по таким табличкам придется разносить абсолютно все возникающие типы контрагентов.
это нормально, главное правильно связи расставить. с чем сложнее работать - вопрос отдельный. как вариант, на payer, customer и т.д. сделать вьюхи с джойнами на контрагента или денормализовать и в них хранить: названия и что-то еще основное нужно легко получать, чтобы не мучаться потом в запросах.

не отражены собственные конторы. тридцать три ООО и ИП для физиков (фантазирую) - вот они будут возникать "с одной стороны" в контракте, а не вбитый фиксированный текст. свои конторы также могут друг для друга быть контрагентами и клиентами.

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

по 2.
сделайте инвойс с привязкой к контракту или заказу, как станет понятнее - отрефакторите. про некую "поставку" и инвойс не очень понял. кто эти связи будет проставлять?

--
расписывайте сценарии по сущностям. угадать всё, сидя в параллельной вселенной не получится.
по тому же контракту - уточните у юриста или главного коммерса. заключается ли он каждый раз, если клиент возит 100 заказов.
...
Рейтинг: 0 / 0
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование БД / 12 сообщений из 12, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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