|
|
|
проектирование таблицы клиентов
|
|||
|---|---|---|---|
|
#18+
Доброго дня. Я новичек - проектирую БД и столкнулся с проблемой.. Есть таблица Zakazi, в которой есть поле, являющееся внешнием ключем - Clients Соответственно есть таблица Clients, в которой номер клиента является первичным ключом. Проблема в том, что клиенты могут быть юр лица, а могут - физлица. Для физлиц нужны поля только ФИО и телефон, для юр.лиц - название предприятия, адрес, реквизиты и так далее.. Т.е. по хорошему физ лица и юр лица должны располагаться в разных таблицах.. Отсюда вопрос...как лучше это реализовать? У меня пока что только две задумки - или объеденить все поля в одну таблицу - но эта задумка глупая. Вторая задумка - в таблице Заказы сделать два поля - fizClients, yurClients... и ограничениями сделать чтобы одно было обязательно пустое, если есть значение во втором. Может кто-нибудь натолкнет на мысль? Спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.05.2012, 11:03 |
|
||
|
проектирование таблицы клиентов
|
|||
|---|---|---|---|
|
#18+
Т.е. по хорошему физ лица и юр лица должны располагаться в разных таблицах..Чушь. Только в одной. Просто набор реквизитов разный. У нас полные реквизиты (банк, Юр.адрес, ОКПО) требуются только для ЮЛ. Учтите, что реквизиты зависят от времени, т.е. достаточно часто меняются (однозначно хранить в отдельной таблице). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.05.2012, 11:10 |
|
||
|
проектирование таблицы клиентов
|
|||
|---|---|---|---|
|
#18+
LSV, поясните плиз.. имеем таблицу Clients с полями... Clients_Num PK FIO Phone Rekv FK и в таблице Rekviziti Rekv_No PK UNP Adress .... Так? И в программе если Rekv != 0, значит - юрлицо? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.05.2012, 11:15 |
|
||
|
проектирование таблицы клиентов
|
|||
|---|---|---|---|
|
#18+
> физ лица и юр лица должны располагаться в разных таблицах.. Разумеется. Разные атрибуты - следствие законодательных и практических ограничений. Ничего необычного в этом нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.05.2012, 11:33 |
|
||
|
проектирование таблицы клиентов
|
|||
|---|---|---|---|
|
#18+
guest_20040621> физ лица и юр лица должны располагаться в разных таблицах.. Разумеется. Разные атрибуты - следствие законодательных и практических ограничений. Ничего необычного в этом нет.Экая чушь. В основой таблице: ID, Название/кратНазвание, тип карточки(Юр/Физ/Проч), признаки актуальности, статусы и т.д. В дополнительных таблицах: Ссылка на осн. таблицу, реквизиты(много разных полей), дата актуальности (актуально с). Ссылки на конт. лиц с телефонами/мейлами/должностями и пр. Конт. Лица - отдельная таблица. Прочие связки один-ко-многим, например наличие у компании сертификатов, допусков, лицензий и т.д. В карточке контрагента могут быть привязаны различные договоры с договорными условиями и датами актуальности. Сделайте функции, кот. умеют выбирать реквизиты на конкретную дату. И пользуйтесь только ими. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.05.2012, 12:22 |
|
||
|
проектирование таблицы клиентов
|
|||
|---|---|---|---|
|
#18+
LSV, Можно детальнее расписать? Не очень хорошо понял.. Для контактных лиц отдельную таблицу, думаю, делать не буду. Итак путаюсь. Да и не в огромных масштабах юр лица идут. И еще появился вариант с промежуточной таблицей Clients_ID Yur_Lico FK Fiz_Lico FK и соответственно 2 таблицы - для юр и физ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.05.2012, 12:29 |
|
||
|
проектирование таблицы клиентов
|
|||
|---|---|---|---|
|
#18+
severekИ еще появился вариант с промежуточной таблицей Clients_ID Yur_Lico FK Fiz_Lico FK и соответственно 2 таблицы - для юр и физ.Вам же ясно сказали: ОДНА Главная таблица . Для нее в отдельных таблицах есть ряд спецификаций (т.е. один-ко-многим). В них может быть что угодно: реквизиты, договора, конт.лица, и пр. ЧТО НЕПОНЯТНО ? зы: Спецификация это как накладная с товарами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.05.2012, 12:48 |
|
||
|
проектирование таблицы клиентов
|
|||
|---|---|---|---|
|
#18+
Физлица и Юрлица могут лежать как в одной так и в разных таблицах. Однозначного рецепта, эффективного в 100% случаев, НЕТ. Выбор варианта зависит от разных условий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.05.2012, 12:51 |
|
||
|
проектирование таблицы клиентов
|
|||
|---|---|---|---|
|
#18+
LSVВам же ясно сказали: ОДНА Главная таблица . Для нее в отдельных таблицах есть ряд спецификаций (т.е. один-ко-многим). В них может быть что угодно: реквизиты, договора, конт.лица, и пр. ЧТО НЕПОНЯТНО ? зы: Спецификация это как накладная с товарами. Хы... сейчас как раз сижу и изучаю все, что обсуждали здесь на эту тему.. Тоже никак не пойму, контрагентов физиков и юриков в одну таблицу сваливать, или по 3 раскидать (общая, физики и юрики) ((((... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.05.2012, 12:54 |
|
||
|
проектирование таблицы клиентов
|
|||
|---|---|---|---|
|
#18+
severek, В общем у меня пока получается такая штука (см. файл)... непонятно пока с отгрузочными реквизита и адресами организаций...в существующей версии типа используют КЛАДР, но судя по данным в БД, нефига они его не используют, там вообще даже для такого чайника как я -помойка... и вообще КЛАДР вроде приказал долго жить, ФИАС вовсю рекламируют... да, кстати, от мени требуют справочник по контрагентам на предприятии... и не судите строго, пжл)))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.05.2012, 13:18 |
|
||
|
проектирование таблицы клиентов
|
|||
|---|---|---|---|
|
#18+
> Отсюда вопрос...как лучше это реализовать? Применяя наследование, оно же отношение подкатегории. Описание как это делается можно найти. например, http://www.sql.ru/forum/actualthread.aspx?tid=918558 или http://sqllessons.com/categories.html > У меня пока что только две задумки - или объеденить все поля в одну таблицу - но > эта задумка глупая. Глупая. > Вторая задумка - в таблице Заказы сделать два поля - fizClients, yurClients... и > ограничениями сделать чтобы одно было обязательно пустое, если есть значение во > втором. Это -- ещё глупее. ссылаться надо на одну таблицу, а вот уже эта таблица должна разветвляться. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.05.2012, 13:30 |
|
||
|
проектирование таблицы клиентов
|
|||
|---|---|---|---|
|
#18+
On 05/03/2012 12:03 PM, severek wrote: > Доброго дня. Я новичек - проектирую БД и столкнулся с проблемой.. Да, ещё можно найти очень подробное описание этой проблематики в документации по Hibernate, раздел называется как-то типа Mapping inheritance. Там действительно (как говорили в теме) есть несколько способов реализации наследования в РБД, около 5 если не ошибаюсь, но только вот только один способ идеален и лишён всех огрехов -- этот. Т.е. по таблице на подкласс, родитель связан с дочерней таблицей 1-к-0 или 1. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.05.2012, 13:33 |
|
||
|
проектирование таблицы клиентов
|
|||
|---|---|---|---|
|
#18+
> Это -- ещё глупее Был более высокого мнения о ваших способностях. Домашнее задание: перечислить [основные] отличия субъектов предпринимательской деятельности и граждан государства с точки зрения законодательных особенностей участия в сделках. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.05.2012, 13:50 |
|
||
|
проектирование таблицы клиентов
|
|||
|---|---|---|---|
|
#18+
severek У меня пока что только две задумки - или объеденить все поля в одну таблицу - но эта задумка глупая.Это один из способов решения. Имеет свои достоинства и свои недостатки. Идеально если сущности скорее одинаковые чем разные. severek Вторая задумка - в таблице Заказы сделать два поля - fizClients, yurClients... и ограничениями сделать чтобы одно было обязательно пустое, если есть значение во втором.Это тоже один из возможных способов решения. Идеален, если сущности скорее разные, чем одинаковые. severek Может кто-нибудь натолкнет на мысль? Про наследование с общей таблицей общих свойств упоминали выше. Тоже со своими достоинствами и недостатками. Какое из решений больше подходит вашей задаче выбирайте сами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.05.2012, 19:15 |
|
||
|
проектирование таблицы клиентов
|
|||
|---|---|---|---|
|
#18+
severek... У меня пока что только две задумки - или объеденить все поля в одну таблицу - но эта задумка глупая. ... Так и делайте. Создайте в табличке "Клиент" признак - "ЭтоФизЛицо", и набор полей, различный для каждого вида клиентов. Не экономьте дисковую память, за это премию не дадут. Ну, общие поля для видов клиентов клиентов поля ("Момент регистрации", "Телефон" и т.п.) пусть остаются общими, конечно. Вообще, отказаться от самого простого варианта можно, но только в случае, когда есть на это причины. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.05.2012, 19:29 |
|
||
|
проектирование таблицы клиентов
|
|||
|---|---|---|---|
|
#18+
severekДоброго дня. Я новичек - проектирую БД и столкнулся с проблемой.. Есть таблица Zakazi, в которой есть поле, являющееся внешнием ключем - Clients Соответственно есть таблица Clients, в которой номер клиента является первичным ключом. Проблема в том, что клиенты могут быть юр лица, а могут - физлица. Для физлиц нужны поля только ФИО и телефон, для юр.лиц - название предприятия, адрес, реквизиты и так далее.. Т.е. по хорошему физ лица и юр лица должны располагаться в разных таблицах.. Отсюда вопрос...как лучше это реализовать? У меня пока что только две задумки - или объеденить все поля в одну таблицу - но эта задумка глупая. Вторая задумка - в таблице Заказы сделать два поля - fizClients, yurClients... и ограничениями сделать чтобы одно было обязательно пустое, если есть значение во втором. Может кто-нибудь натолкнет на мысль? Спасибо Вы не БД проектируете, а весьма специфическую реляционную БД. Когда проектируют БД, проблем не возникает... Потому что думают не о таблицах. А о людях, например:) Ведь "физическое лицо" - это же человек. И сотрудник, например, это тоже человек. Нужно шире смотреть на ситуацию, когда проектируешь БД, иначе Вам удачи не видать:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.05.2012, 21:29 |
|
||
|
проектирование таблицы клиентов
|
|||
|---|---|---|---|
|
#18+
[quot guest_20040621]> Это -- ещё глупее Был более высокого мнения о ваших способностях. Ты не ошибался. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.05.2012, 23:26 |
|
||
|
проектирование таблицы клиентов
|
|||
|---|---|---|---|
|
#18+
> Ты не ошибался К сожалению, ошибался. От плинтуса вы очень невысоко. Домашнее задание в силе. На всякий случай: с [вырезано цензурой] брудершафтов не пью. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.05.2012, 23:42 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=37780231&tid=1541701]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
40ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
37ms |
get tp. blocked users: |
1ms |
| others: | 201ms |
| total: | 305ms |
| 0 / 0 |
