|
|
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
этот вопрос вроде как плодотворно обсудили здесь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2010, 21:35 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
уТКаэтот вопрос вроде как плодотворно обсудили здесь В этом обсуждении как-то незамеченным остался философский вопрос: кого считать одним и тем же контрагентом? Если для фискальных целей очевидно, что юридическое лицо "ООО Василек" и физическое лицо "Вася" это никак не связанные вещи (ну есть некоторые нюансы по тому, кто и как будет отвечать по долгам Васи), то для фирмы у которой этот Вася покупал 10 лет электроинструмент, это далеко не так. Также возникают проблемы с отчетностью за разное время и т.п. Поэтому обычно компании приходят к тому, что существует некий контрагент, который является для них единым лицом согласно неким внутренним бизнес-правилам. Отсюда автоматически получается, что время жизни контрагента, как единого лица, теоретически может быть больше чем время жизни любых его атрибутов, включая и тип юр. лица. Соответственно, если мы ведем две отдельные таблицы для контрагентов юриков и физиков получается, что вполне ДОПУСТИМО существование в обоих таблицах ID одного и того же контрагента (разруливать кем он является сейчас, и кем и когда являлся ранее, можно через промежуточную темпоральную таблицу)! Более того, никто не мешает тому же Василию благополучно разориться как ООО и стать снова Василием, а потом опять стать юриком, но уже "ЗАО "Эх ухнем"". Т.е. получается, что в обоих таблицах реквизитов возникнет необходимость иметь по несколько записей для контрагента с одинаковым ID (т.е. АК надо стоить по ID контрагента и ID из промежуточной темпоральной таблице)! Но и это не все, если мы начали продавать свой инструмент за рубеж, неизбежно понадобятся свои реквизиты и бизнес-правила и для них. Мы опять вернемся к вопросу о том, куда добавлять эти реквизиты? В уже существующие таблицы, где они явно будут "путаться под ногами" для отечественных контрагентов, или городить для них свои таблицы? Боюсь, что единого ответа не будет. Но если оценить реальное кол-во контрагентов, то зачастую решение хранить все реквизиты в одной отдельной таблице может оказаться не плохим вариантом, более того, совсем не очевидна необходимость вязать в единое целое одинаковые по названию, но разные по смыслу поля, так вполне можно допустить поле для ИНН для юриков и поле ИНН для физиков и т.п. Разумеется, если мы чего не учли, например, возможность вышеупомянутого сотрудничества с иностранцами, никуда мы не денемся от дописывания бизнес-правил и добавления полей в таблицу реквизитов, но это может оказаться проще, чем вариант создания доп. таблиц с практическим дублированием ряда бизнес-правил по реально совпадающим по смыслу полям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2010, 10:47 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
iscrafmLSV Совпадение ФИО и названия для Физ. - тавтология. Ничего не поделаешь. это не тавтология, это недопонимание различия между понятиями "данные" и "информация", или физической и логической моделью. Данные - это 250 символов, а информация - в одном случае ФИО человека, в другом - наименование компании. Вы правы, ничего сверхестественного. Хорошо, для Физ.лица название ФИО (строго в таком порядке). Если сделать в базе Название Юр/Физ лица одним полем, то кому доверить проверку на правильность ввода - интерфейсу(будет 3 поля - Фамиллия Имя Отчетсво) ?? Я считатал всегда, что целостность данных должна обеспечивать сама БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2010, 13:36 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
blest, база данных только хранит сведения как есть. Целостность данных проверяет СУБД , а обеспечивает эту целостность в первую очередь пользователь, а затем приложение. Сначала проверку данных осуществляет пользователь, потом приложение и наконец СУБД. Если кто то в этой цепочке косячит, а следующий не имеет адекватной проверки, то и в БД сведения будут кривыми. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2010, 14:42 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
blestХорошо, для Физ.лица название ФИО (строго в таком порядке). Если сделать в базе Название Юр/Физ лица одним полем, то кому доверить проверку на правильность ввода - интерфейсу(будет 3 поля - Фамиллия Имя Отчетсво) 1. нет нужды писать разные данные в одно поле. В Оракле пустые поля почти не занимают места. В других структурах данных могут быть конструкции типа C'шного union или ASN'овского CHOICE. XML опять же поддерживает вариативность атрибутов... 2. Для проверки на уровне СУБД несложно сделать декларативное ограничение целостности. Т.е. в зависимости от формы собственности (частное лицо, ЧП, организация и т.п.) можно требовать заполнение одних полей и незаполнение других. 3. качество данных в первую очередь определяет не их проверка в момент изменения, а их использование. Ненужные данные рано или поздно потеряют актуальность. Ошибки в нужных данных обычно достаточно быстро выявляются когда их начинают использовать в отчётах, вычислениях, и т.п. В системе должен быть предусмотрен механизм отрицательной обратной связи по ошибкам данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2010, 14:57 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
Единственная таблица - бредовое решение во всех отношениях. Точка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2010, 21:18 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
Не ORMЕдинственная таблица - бредовое решение во всех отношениях. Точка. Нет, ну если честно, то в единой таблице с есть решиние имхо. При регистрации Фирмы или ИП регистрациоонная форма ОДНА. Но мой вопрос по-породу ФИО остается актуальным. И может быть есть и другие пункты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2010, 04:35 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
Нет там никакого решения, а один только мало внятный бардак ради весьма сомнительной экономии на лишнем Join. Для любителей произодительности - две таблицы с уникальными Id. Самодокументируемость схемы, отсутствие лишних индексов, меньше длина строки, проще проверки, возможность применения кодогенераторов\ORM для построения клиентской части и тд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2010, 12:12 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
blestНет, ну если честно, то в единой таблице с есть решиние имхо. При регистрации Фирмы или ИП регистрациоонная форма ОДНА. Но мой вопрос по-породу ФИО остается актуальным. И может быть есть и другие пункты. Одна сущность - одна таблица+подчиненные (если есть). Формы редактирования разные - зависит от типа сущности и, возможно, от других причин. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2010, 10:06 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
blestНо мой вопрос по-породу ФИО остается актуальным. И может быть есть и другие пункты. Давайте обратимся к гигантам индустрии. Смотрим объектную СУБД оракл. Как в ней можно реализовать твою схему?... Создаём тип Контрагент, Создаём подтип Физ_лицо от Контрагент Создаём подтип Юр_лицо от Контрагент Можно создать таблицы из Физ_лицо и Юр_лицо. Впринципе неплохо, но тогда тип Контрагент не сильно помогает нам. Так например нам нужно знать в ккой таблице хранятся контрагенты каждого типа, вместо того, чтобы просто сохранять их в одной таблице. Висячие ссылки не запретишь. И т.п. Можно создать таблицу из Контрагент. Теперь там, где Контрагенты не подразделяются на Физ и Юр, мы можем оперировать обобщённым понятием. Что касается хранения атрибутов, то оракл в недрах БД создаст таблицу в которой просто перечислит все поля сначала из Контрагент, потом из Физ_лицо и наконец из Юр_лицо (точнее, порядок тут не важен). Отображение понятий ООП на реляционную модель зачастую выглядит коряво. Но для того объектные субд и создаются, чтобы скрыть эту корявость от пользователя. _модОдна сущность - одна таблица+подчиненные (если есть). Формы редактирования разные - зависит от типа сущности и, возможно, от других причин. Слабось ER моделирования в том, что нет строгого определения сущности. Используя разные подходы, мы можем получать разный набор сущностей и соответсвующих таблиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2010, 13:47 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
LSVОтдельные таблицы для Физ. и Юр. - идиотство. Тоже самое для Поставщик-Покупатель. +500. Когда уже прекратится это обсуждение раз и навсегда? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2010, 13:42 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
mcureenabДавайте обратимся к гигантам индустрии Хотите их всуе упомянуть? Что ж. В SAP дебиторы отдельно от кредиторов... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2010, 13:45 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
blestНо мой вопрос по-породу ФИО остается актуальным Какой именно вопрос? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2010, 13:46 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
Сергей ВаскецовmcureenabДавайте обратимся к гигантам индустрииХотите их всуе упомянуть? Что ж. В SAP дебиторы отдельно от кредиторов...В Navision отдельно. Гиганты индустрии - не показатель. Там полно мегакосяков. И это один из них. Видимо он пришел по наследству с незапамятных DOS-времён, когда для простоты управления и безопасности лепили две таблицы, а SQL в помине не было. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2010, 14:31 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
mcureenab Слабось ER моделирования в том, что нет строгого определения сущности. А его в принципе нет. Выбор сущностей - это момент проектирования. В данном случае я бы выбрал одну сущность - контрагент. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2010, 17:31 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
Сергей ВаскецовLSVОтдельные таблицы для Физ. и Юр. - идиотство. Тоже самое для Поставщик-Покупатель. +500. Когда уже прекратится это обсуждение раз и навсегда? Прекращаем. blestЕсть сущность контрагент - есилф физлицо, то нужно вносить Фамилию, Имя, Отчество - 3 поля. Если юрлицо, то 1 поле - название контрагента. Можно сделать одной таблицей, с четырмя полями. В первом случае будет заполняться одно поле, во втором другие 3 поля. Насколько это правильно и стоит ли так делать? Это один из способов реализации полиморфизма в реляционной БД. Так делают в промышленных СУБД и в том есть определённые преимущества, как впрочем и недостатки. Если не нравится, создавайте другие сущности - без абстракций. Вероятно введение абстрактной сущности Контрагент связано с желанием исключить из модели множетсвенные связи некоторых сущностей с разными типами контрагентов. Но во первых таких связей может и не быть на самом деле (зачастую проектировщики пытаются хранить в БД временные связи, которые возникают и пропадают только в процессе выполнения некоторых операций), во вторых переходя к физической модели БД мы можем реализовать их разными способами, в частности через таблицу связей. Наконец сама сущность Контрагент во всех её проявлениях может быть плодом фантазии проектировщика (например, из сущности Контракт зачемто выносят в отдельную сущность атрибуты сторон, создавая в БД лишние сущности и связи, тогда как можно было обойтись представлением БД из тех же Контрактов, Заказов, Контактов и т.п.). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2010, 19:02 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
Сергей ВаскецовblestНо мой вопрос по-породу ФИО остается актуальным Какой именно вопрос? Хорошо, для Физ.лица название ФИО (строго в таком порядке). Если сделать в базе Название Юр/Физ лица одним полем, то кому доверить проверку на правильность ввода - интерфейсу(будет 3 поля - Фамиллия Имя Отчетсво) ?? Я считатал всегда, что целостность данных должна обеспечивать сама БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2010, 13:43 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
blestХорошо, для Физ.лица название ФИО (строго в таком порядке). Если сделать в базе Название Юр/Физ лица одним полем, то кому доверить проверку на правильность ввода - интерфейсу(будет 3 поля - Фамиллия Имя Отчетсво) ?? Я считатал всегда, что целостность данных должна обеспечивать сама БД. целостность данных <> правилам ввода. Богу богово, кесарю кесарево. База проверяет целостность, правила ввода проверяет интерфейс, всё логично. ЗЫ замечание безотносительно основной обсуждаемой темы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2010, 14:34 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
blest Это вопрос типа "сколько полей сделать под ФИО"? blestЕсли сделать в базе Название Юр/Физ лица одним полем Что значит "если"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2010, 15:42 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
Сергей Васкецовblest Это вопрос типа "сколько полей сделать под ФИО"? blestЕсли сделать в базе Название Юр/Физ лица одним полем Что значит "если"? Это значит, что при другом варианте можно сделать 3 поля, и в другой таблице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2010, 17:46 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
blestЭто значит, что при другом варианте можно сделать 3 поля, и в другой таблице. И в чем проблема? Вам необходимо отдельно иметь имя, фамилию? Или достаточно просто иметь некое наименование, например, для отчета "Список должников бабла"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2010, 17:48 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
У нас абстрактная сущность Контрагент существует не абстрактно - в договоре Поле Контрагент используется очень активно при этом не не надо мучаться как в это поле запихнуть Физика или Юрика ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2010, 11:07 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
Сергей ВаскецовblestЭто значит, что при другом варианте можно сделать 3 поля, и в другой таблице. И в чем проблема? Вам необходимо отдельно иметь имя, фамилию? Или достаточно просто иметь некое наименование, например, для отчета "Список должников бабла"? 100%. Думаю здесь просто отдает борьбой за "нормализацию" и прочие академические каноны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2010, 11:27 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
spУ нас абстрактная сущность Контрагент существует не абстрактно - в договоре Поле Контрагент используется очень активно при этом не не надо мучаться как в это поле запихнуть Физика или Юрика С ваших слов можно понять, что сущности Контрагент у вас нет. Зато есть одноимённый атрибут сущности Договор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2010, 13:08 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=36472415&tid=1542842]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
65ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
| others: | 210ms |
| total: | 374ms |

| 0 / 0 |
