Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование бд / 20 сообщений из 20, страница 1 из 1
19.05.2006, 19:08
    #33739703
Kulta
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование бд
Доброе время суток всем!
У меня следующая проблема, которую я никак не могу решить. Есть следующая схемка (см.рис). На ней table1, table2, table3. Пусть это будут Клиенты, Поставщики, Служащие, не суть важно. Есть таблица Address в ней хранятся адреса Клиентов, Поставщиков, Служащих, причем у одного клиента, поставщика или служащего адресов может быть несколько, т.е. связь М-М. Еще есть табличка Passport она хранить паспортные данные. Естественно у одного Клиента, Поставщика и Служащего должна быть только одна запись в Passport (не может у человека быть >1 паспорта). Вопрос в следующем: как правильно соеденить таблицы, либо как переделать структуру чтоб она удовлетворяла условиям выше?
...
Рейтинг: 0 / 0
19.05.2006, 19:33
    #33739745
Br. Potemkin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование бд
Глупости... зачем стока таблиц? Короче так нада:
Храни всех контрагентов в одной таблице tbl_Partrners: ID_Partner, PartnerName,..., ID_Partner .
Это тебя избавит от многих проблем. Отличай их по признаку ID_PartnerType. Признак храни в другой таблице. - tbl_PartnerType: ID_PartnerTyep, PartnerTypeName
Теперь ты можешь смело вязать их с адресами: tbl_Address: ID_Address, Address, ID_Partner .
А с паспартами еще проще. Эти данные не могут дублироваться, они уникальны по природе => нет надобности их отделять от контрагентов. Храни все поля в той же таблице где и клиенты. Если не хочешь - тогда так
tbl_Passport: ID_Passport, PassNum, ID_Partner.
...
Рейтинг: 0 / 0
19.05.2006, 19:38
    #33739755
proposed amendment
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование бд
Kulta(не может у человека быть >1 паспорта).

да запросто...

уже и не говоря о том, что в ряде случаев нужно хранить и историю замены паспортов
...
Рейтинг: 0 / 0
19.05.2006, 20:36
    #33739835
Br. Potemkin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование бд
ну тогда второй вариант.. кто мешает? таблица
tbl_Passport: ID_Passport, PassNum, ID_Partner.
...
Рейтинг: 0 / 0
19.05.2006, 20:37
    #33739837
Br. Potemkin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование бд
Опыт подсказывает, что нужно объединять справочники такого рода. Это водальнейшем сильно облегчает работу...
...
Рейтинг: 0 / 0
22.05.2006, 09:21
    #33741626
Kulta
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование бд
Насчет объединения всех в одну таблицу. Это не пойдет т.к. Table1, Table2, Table3 разные сущности, и нужно их хранить в разных таблицах (так надо сделать). Историю замены паспортов хранить нет необходимости (в данном контексте этого никода не будет)
...
Рейтинг: 0 / 0
22.05.2006, 13:15
    #33742493
sergey888
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование бд
Клиент и Поставщик - одна сущность и называется она "Юридическое лицо"
Сотрудник - "Физическое лицо"
...
Рейтинг: 0 / 0
22.05.2006, 15:24
    #33742868
ModelR
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование бд
KultaНасчет объединения всех в одну таблицу. Это не пойдет т.к. Table1, Table2, Table3 разные сущности, и нужно их хранить в разных таблицах (так надо сделать). Историю замены паспортов хранить нет необходимости (в данном контексте этого никода не будет)А один паспорт может принадлежать разным людям? если нет, то фактически имеем
Паспорт=Человек, а Клиент, Поставщик и Служащий подтипы Человек.
Исключающее наследование см. по соседству.

Вариант: Таблицу паспортов совсем убрать (если она больше ни для чего не нужна), а паспорт - просто поле, как и Name.

>причем у одного клиента, поставщика или служащего адресов может быть несколько, т.е. связь М-М.

а может быть 1:M. Вы опять не рассказали про обратное отношение.
...
Рейтинг: 0 / 0
22.05.2006, 16:11
    #33743021
Kulta
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование бд
Не совсем понял про "обратное отношение". Насчет "причем у одного клиента, поставщика или служащего адресов может быть несколько, т.е. связь М-М. " признаюсь ошибся, конечно же там должно быть 1(table1,table2,table3):М(address).
Мне кажется, что все рассуждения приводят к примерно такой схеме: table1 (это человек) + дополнительное поле пределяющее тип человека (Клиент, Поставщик и Служащий) + ключ на адрес + ключ на паспорт. Но опять же изначально хотел иметь 3и таблицы + 2а (может даже один, если без паспорта) справочника
...
Рейтинг: 0 / 0
22.05.2006, 16:26
    #33743099
Dino
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование бд
А если один и тот же человек и клиент и поставщик и не дай бог служащий?
Что делать ;)
Будем дублировать информацию?!
Вообщем вот очень интересная статейка
http://blogs.slcdug.org/petermorris/archive/2006/03/30/3903.aspx
...
Рейтинг: 0 / 0
22.05.2006, 16:58
    #33743228
sergey888
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование бд
А если один и тот же человек и клиент и поставщик и не дай бог служащий?

Это что, автоматизация публичного дома?
...
Рейтинг: 0 / 0
22.05.2006, 17:42
    #33743414
Br. Potemkin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование бд
sergey888Клиент и Поставщик - одна сущность и называется она "Юридическое лицо"
Сотрудник - "Физическое лицо"

Это глупо. Поставщиком и клиетом может быть и физическое лицо. А если взять и собрать их в одну табличку, просто добавить туда полей, если надо... все становиться предельно просто...
А вот Kulta правильно заметил про адреса... может быть и отношение M:M.
...
Рейтинг: 0 / 0
22.05.2006, 18:11
    #33743505
proposed amendment
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование бд
Br. Potemkin все становиться предельно просто...

угу...

тут лучшие умы Российской школы программирования бъются друг с другом насмерть, половина тредов этого раздела завалена телами физиков и юриков вперемешку с супертипами, над полем жестокой битвы витает запах Иприта, Зарина а также EAV и других V-газов...

а ему все становиться предельно просто...

ЗЫ

молодой человек, возвратные формы глаголов (с суфиксом "-ся") в третьем лице пишуцца без мяхкова знака.
...
Рейтинг: 0 / 0
22.05.2006, 18:28
    #33743558
sergey888
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование бд
Поставщиком и клиетом может быть и физическое лицо.А если взять и собрать их в одну табличку, просто добавить туда полей, если надо... все становиться предельно просто...


И как это будет выглядеть на форме?
...
Рейтинг: 0 / 0
23.05.2006, 03:31
    #33744010
Br. Potemkin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование бд
proposed amendment
тут лучшие умы Российской школы программирования бъются друг с другом насмерть

я так понимаю тут вопросы решаются, а побиться насмерть это в другом месте.
...
Рейтинг: 0 / 0
23.05.2006, 03:35
    #33744012
Br. Potemkin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование бд
sergey888И как это будет выглядеть на форме?

Очень красиво: отличать партнеров от сотрудников можно с помощью типа (ID_PartnerType) выше про него говорил уже. Хочешь - юзай представления. И будет тебе на уровне представлений 3 отдельных справочника.
...
Рейтинг: 0 / 0
23.05.2006, 11:00
    #33744522
Dino
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование бд
sergey888 А если один и тот же человек и клиент и поставщик и не дай бог служащий?

Это что, автоматизация публичного дома?

Ой, а что такого быть не может?
Как минимум один человек и даже одна компания может быть и поставщиком и клиентом.
Нет можете конечно наставить себе кучу ограничений, что один человек/компания только поставщик или только клиент.
Но потом не плачьте когда будете предлагать своим пользователям вводить одну и ту же информацию в нескольких местах одновременно или писать хранимые процедуры/триггеры для синхронизации данных.
...
Рейтинг: 0 / 0
23.05.2006, 13:02
    #33745146
ModelR
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование бд
KultaНе совсем понял про "обратное отношение". Да, лучше сказать прямая/обратная связь.
Каждый Человек имеет (M) Адрес / Каждый Адрес принадлежит (1) Человек KultaНо опять же изначально хотел иметь 3и таблицы + 2а (может даже один, если без паспорта) справочника С учетом высказанных коллегами опасений? ОК, структурой БД проект не исчерпывается. Можно рулить и в других местах.
...
Рейтинг: 0 / 0
23.05.2006, 13:20
    #33745228
proposed amendment
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование бд
ModelR
Каждый Человек имеет (M) Адрес / Каждый Адрес принадлежит (1) Человек.

довольно давно использую схему многие-ко-многим и в телефонном справочнике и в адресной книге

один адрес может принадлежать разным людям (компаниям) один телефон может принадлежать разным людям (компаниям)

иногда удается выяснить довольно любопытные вещи
...
Рейтинг: 0 / 0
23.05.2006, 13:50
    #33745399
ModelR
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование бд
proposed amendmentодин адрес может принадлежать разным людям (компаниям) один телефон может принадлежать разным людям (компаниям)Да речь шла чисто о форме, а по использованию +1.
...
Рейтинг: 0 / 0
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование бд / 20 сообщений из 20, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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