|
|
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
Есть сущность контрагент - есилф физлицо, то нужно вносить Фамилию, Имя, Отчество - 3 поля. Если юрлицо, то 1 поле - название контрагента. Можно сделать одной таблицей, с четырмя полями. В первом случае будет заполняться одно поле, во втором другие 3 поля. Насколько это правильно и стоит ли так делать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2010, 19:23 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
В таком случае разбивают на три таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2010, 08:48 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
А есть еще ИНН, как бы общий, но разной длины и у физлиц необязательный, а у юр - обязательный (в РФ). С уважением, Naf ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2010, 09:04 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
Т.е. я так понимаю основная таблица - контрагенты, содержащая внешний ключ на таблицу физ.лицо и вн.ключ на таблица юр.лицо? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2010, 12:41 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
blestТ.е. я так понимаю основная таблица - контрагенты, содержащая внешний ключ на таблицу физ.лицо и вн.ключ на таблица юр.лицо? у них внешние ключи могут совпадать с примарными ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2010, 12:43 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
И направлены в другую сторону - к контрагенту ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2010, 13:56 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
blestНасколько это правильно и стоит ли так делать? Это неправильно концептуально. В информационной модели так делать не следует. В противном случае вам придётся написать объёмный комментарий к такой сущности. Если речь идёт о реализации, то оракл именно так и поступает, но внутри себя. На уровне SQL запросов пользователь получает из таблицы объекты разных типов, с разным набором полей. Но впринципе это сокрытие несущественно. Реализация не сложная и достаточно "прозрачная" для пользователей БД. Можно и без объектной надстройки обойтись. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2010, 14:43 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
------------------------И направлены в другую сторону - к контрагенту А ну да, как раз таблицы юр.лицо и физ.лицо должны ссылать на контрагенты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2010, 17:50 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
blest[quot ------------------------]И направлены в другую сторону - к контрагенту А ну да, как раз таблицы юр.лицо и физ.лицо должны ссылать на контрагенты.[/quot ага ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2010, 19:15 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
NafА есть еще ИНН, как бы общий, но разной длины и у физлиц необязательный, а у юр - обязательный (в РФ). С уважением, Naf а еще бывают такие неуникальные случаи изменения ИНН и бывают их кучи одинаковых!!! ))) в украине все возможно )))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2010, 09:51 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
Toshikblest[quot ------------------------]И направлены в другую сторону - к контрагенту А ну да, как раз таблицы юр.лицо и физ.лицо должны ссылать на контрагенты.[/quot ага Еще один момент. Таблицы будут такого вида: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Но как будет гарантироваться целостность БД? Контрагент может быть или Юр.лицом или Физ.лицом. Но по такой схеме в таблицах Юр.лица и Физ.лица айдишники контрагентов могут совпадать. Что делать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2010, 16:29 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
Считать их предпринимателями без образования юридического лица :) А если серьезно, то очень редки ситуации, когда с помощью только первичных ключей и констрейнтов можно задать все реально имеющиеся ограничения. Даже то, что актив равен пассиву. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2010, 16:53 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
-----------------------------Считать их предпринимателями без образования юридического лица :) А если серьезно, то очень редки ситуации, когда с помощью только первичных ключей и констрейнтов можно задать все реально имеющиеся ограничения. Даже то, что актив равен пассиву. А какими еще средствами тогда можно еще пользоваться? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2010, 17:03 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
blest, Я бы не стал экономить место на текстовых атрибутах для справочника контрагентов, если он у вас не на сотни тысяч человек, то экономия получится грошовой, а структура базы усложнится. Вообще соотношений типа (1:1) OR (1:1) лучше избегать. Но дело ваше. Попробуйте сделать так (псевдокод, проверять некогда) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Теперь вы никак не сможете вставить запись из contractors с одним же и тем же ID + TYPE_C сразу в разные таблицы, за этим проследит поле TYPE_C, точнее constraints в подчиненных таблицах. Минус в том, что constraints можно отключать, но и FK тоже можно удалять. :) В принципе можно изощряться в этом направлении сколько душе угодно, например, генерировать значения последовательности для ID первичной таблицы из двух разных диапазонов (в зависимости от типа контрагента) и вставить в constraints подчиненных таблиц проверку на эти диапазоны, тогда не понадобится составной ключ, ну и т.д и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2010, 18:57 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
blestToshikblest[quot ------------------------]И направлены в другую сторону - к контрагенту А ну да, как раз таблицы юр.лицо и физ.лицо должны ссылать на контрагенты.[/quot ага Еще один момент. Таблицы будут такого вида: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Но как будет гарантироваться целостность БД? Контрагент может быть или Юр.лицом или Физ.лицом. Но по такой схеме в таблицах Юр.лица и Физ.лица айдишники контрагентов могут совпадать. Что делать? генерировать ID только в table Контрагенты сначала и вставлять в соответствующие таблицы Физ_Лица и ЮР_Лица ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2010, 19:02 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
spblestToshikblest[quot ------------------------]И направлены в другую сторону - к контрагенту А ну да, как раз таблицы юр.лицо и физ.лицо должны ссылать на контрагенты.[/quot ага Еще один момент. Таблицы будут такого вида: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Но как будет гарантироваться целостность БД? Контрагент может быть или Юр.лицом или Физ.лицом. Но по такой схеме в таблицах Юр.лица и Физ.лица айдишники контрагентов могут совпадать. Что делать? генерировать ID только в table Контрагенты сначала и вставлять в соответствующие таблицы Физ_Лица и ЮР_Лица Ну я так и собирался делать в процедуре по добавлению контрагентов, но это ведь не гарантирует, что другой программист взяв эти таблицы не напихает в Юр.лица и Физ.лица одинаковые айдишники ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2010, 19:23 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
blestно это ведь не гарантирует, что другой программист взяв эти таблицы не напихает в Юр.лица и Физ.лица одинаковые айдишники а что страшного случится если напихает? ты же не собираешься их использовать без базового ENTRY_ID? никого не пугает что в таблицах PRODUCTS и DOCUMENTS могут быть одинаковые <RECORD>_ID а вот одинаковые ENTITY_ID и IDENTITY_ID беспокоят почему? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2010, 19:36 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
carperblest, Я бы не стал экономить место на текстовых атрибутах для справочника контрагентов, если он у вас не на сотни тысяч человек, то экономия получится грошовой, а структура базы усложнится. Вообще соотношений типа (1:1) OR (1:1) лучше избегать. Но дело ваше. Попробуйте сделать так (псевдокод, проверять некогда) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Теперь вы никак не сможете вставить запись из contractors с одним же и тем же ID + TYPE_C сразу в разные таблицы, за этим проследит поле TYPE_C, точнее constraints в подчиненных таблицах. Минус в том, что constraints можно отключать, но и FK тоже можно удалять. :) В принципе можно изощряться в этом направлении сколько душе угодно, например, генерировать значения последовательности для ID первичной таблицы из двух разных диапазонов (в зависимости от типа контрагента) и вставить в constraints подчиненных таблиц проверку на эти диапазоны, тогда не понадобится составной ключ, ну и т.д и т.п. Ну да, это есть вариант. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2010, 19:38 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
blestЕсть сущность контрагент - есилф физлицо, то нужно вносить Фамилию, Имя, Отчество - 3 поля. Если юрлицо, то 1 поле - название контрагента. Можно сделать одной таблицей, с четырмя полями. В первом случае будет заполняться одно поле, во втором другие 3 поля. Насколько это правильно и стоит ли так делать? Есть 3 классических варианта решения вопроса: 1) 1 таблица (супертаблица): Контрагенты Достоинства: простота в понимании Недостатки: несколько пониженная надежность (проблема сделать так чтобы ООО "Рога и копыта" не стало директором ОАО "МММ") 2) 2 таблицы: Юрики и Физики. Вариант тупой ибо ссылочная целостность не реализуема вообще. Рассматривать не будем ибо юзать этот вариант не профессионально. ))) 3) 3 таблицы: Контрагенты (содержащие общие для физиков и юриков поля), Юрики и Физики содержащие специфические поля. Достоинства: надежность и правильность с точки зрения теории Недостатки: несколько большая сложность в реализации по сравнению с в.1 P.S. Я когда-то у Алекса Усова из ru.delphi.db спросил примерно тоже самое.... году эдак в 1997-1998. ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2010, 04:35 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
2 Алексей Статюха К контрагенту должен прилагаться набор некоторых реквизитов (сколь угодно разных). Какая проблема разделить реквизиты на: 1. Для всех. 2. Для Юр. 3. Для Физ. и т.д. ?? Решение: Таблица контрагентов, таблица реквизитов, таблица настроек. Разновидностей контрагентов может быть гораздо больше, чем Юр и Физ. Зависит от задачи. ЗЫ: Отдельные таблицы для Физ. и Юр. - идиотство. Тоже самое для Поставщик-Покупатель. Точка. Дальше можно не обсуждать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2010, 11:29 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
LSV2 Алексей Статюха К контрагенту должен прилагаться набор некоторых реквизитов (сколь угодно разных). Какая проблема разделить реквизиты на: 1. Для всех. 2. Для Юр. 3. Для Физ. и т.д. ?? Решение: Таблица контрагентов, таблица реквизитов, таблица настроек. Разновидностей контрагентов может быть гораздо больше, чем Юр и Физ. Зависит от задачи. ЗЫ: Отдельные таблицы для Физ. и Юр. - идиотство. Тоже самое для Поставщик-Покупатель. Точка. Дальше можно не обсуждать. Тоесть по-Вашему это верно когда есть расплывчатое поле Название которое в одной этой таблице и название Юрика и если че - ФИО ????? !!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2010, 14:18 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
spТоесть по-Вашему это верно когда есть расплывчатое поле Название которое в одной этой таблице и название Юрика и если че - ФИО ????? !!!По моему подобный вопрос нужно формулировать точнее. :) Совпадение ФИО и названия для Физ. - тавтология. Ничего не поделаешь. Но ничего страшного тут не вижу. Предлагаете для этого завести отдельную таблицу ? А еще для 20..50 других свойств ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2010, 15:38 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
LSVspТоесть по-Вашему это верно когда есть расплывчатое поле Название которое в одной этой таблице и название Юрика и если че - ФИО ????? !!!По моему подобный вопрос нужно формулировать точнее. :) Совпадение ФИО и названия для Физ. - тавтология. Ничего не поделаешь. Но ничего страшного тут не вижу. Предлагаете для этого завести отдельную таблицу ? А еще для 20..50 других свойств ? И дать этой таблице название Dustbin(мусорное ведро) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2010, 15:57 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
LSV Совпадение ФИО и названия для Физ. - тавтология. Ничего не поделаешь. это не тавтология, это недопонимание различия между понятиями "данные" и "информация", или физической и логической моделью. Данные - это 250 символов, а информация - в одном случае ФИО человека, в другом - наименование компании. Вы правы, ничего сверхестественного. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2010, 16:53 |
|
||
|
Создание таблицы контрагентов
|
|||
|---|---|---|---|
|
#18+
Алексей Статюха3) 3 таблицы: Контрагенты (содержащие общие для физиков и юриков поля), Юрики и Физики содержащие специфические поля. Достоинства: надежность и правильность с точки зрения теории Недостатки: несколько большая сложность в реализации по сравнению с в.1А если к общей таблице прилепить ссылки на специфические таблицы и ограничение что заполнена (not null) может быть только одна ссылка, то мы вернемся к варианту 1 в виде вьюхи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2010, 18:40 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=78&tid=1542842]: |
0ms |
get settings: |
10ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
57ms |
get topic data: |
8ms |
get forum data: |
3ms |
get page messages: |
66ms |
get tp. blocked users: |
1ms |
| others: | 226ms |
| total: | 394ms |

| 0 / 0 |
