|
|
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
Здравствуйте! Такая проблема при проектировании БД, на приложенном рисунке часть таблиц, завязанных на главной таблице tbl_clients. Необходимо каждый атрибут со связями многие-ко-многим (например, несколько различных адресов у клиента, или несколько контактных телефонов) хранить во взяимосвязи с его временем действия (т.е. как бы хранить историю изменений (например, при переезде клиента у него сменился адрес, но мне нужно знать всего его адреса для истории). Наиболее простым решением мне показалось объединение атрибутов через промежуточные таблицы, которые по каждой записи будут хранить и время ее действия. Верно ли это? Такое чувство, что база получается ненормализованной. У меня такое чувство, что я что-то неверно делаю, но с другой стороны мне кажется верным такое решение... В общем, я запутался. Что делать? Правильное это решение или нет?.. Если нет, то в какую сторону "копать"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 16:44 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
Единственное замечание (персонально моё) - Имя клиента тоже может меняться. Неразумно его аттрибутом в Вашем Универсальном Блоке держать. А вообще - вполне логичное и главное - интересное решение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 17:02 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
Mr Marmelad, А имя (которое shortName и fullName в основной таблице клиентов), в этой таблице - не основное, просто справочное, при выставлении счетов и т.п. будут выбираться обязательно из других таблиц. Эти поля скорее для менеджеров отдела продаж нужны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 17:15 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
Если так - то мой вердикт - Очень Положительно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 17:24 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
kuznecov.sg пишет: > Такая проблема при проектировании БД, на приложенном рисунке часть Я вот не понял 2 вещи: -- у вас Клиент к (например) адресу относится как многие-ко-многим. Это зачем ? Я не знаю, может это и нужно, но в принципе обычно делают Клиент к адресу (или ещё чему-то) как один-ко-многим. Потому что вам нет смысла (обычно) отслеживать, живут ли 10 ваших клиентов в одном месте. Если есть - то на здоровье, конечно. Но вот с паспортом вы кажется совсем уже перемудрили - один паспорт двум людям вроде бы не выдают. У вас - вроде можно (там картинка обрезана, не видно точно). Наверное, надо с этим разобраться. -- Второе (вытекает из первого). Допустим, что да, вам там действительно нужно многие-ко-многим. Тогда решите, период действия ЧЕГО вы храните в вашей БД ? Давайте рассмотрим на примере телефона. Телефон сам по себе может быть аннулирован. Был телефон - и сняли. Или там была SIM-карта - растроргли договор. Это - один аспект. Кроме этого, вы говорите у себя в БД: "мой клиент такой-то доступен по такому телефону". "мой клиент Другой доступен по тому же телефону". Далее, проходит время, и первый клиент перестаёт быть доступен по этому телефону. А второй - остаётся. Соответственно, решите, что вам надо, и либо убейте многие-ко-многим, оставив один-ко-многим, и перенесите период в часть "многие" (в атрибут), либо оставьте многие-ко-многим, но решите, где быть периоду: -- в связи -- в атрибуте -- и там, и там. (кажется такое очень избыточно, но кто вас знает что там вам надо). И последнее (отдельное зам.). Кажется контакты (contactID где) могут быть либо e-mail, либо сайт. Я бы сделал разные виды контактов (кстати туда и телефон, и почтовый адрес можно добавить), и их бы связывал - у вас всё равно же многие-ко-многим. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 18:48 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
Вот Тут я с коллегой MasterZiv не совсем согласен. Позвольте высказать своё мнение. Не знаю законов вашего бизнеса коллега. Но И адреса и пасспорта вполне могут иметь разбивку Много - Много. Одит и тот же клиент может имень разные адреса и имена И на одном адресе могут быть зарегистрированы многие клиенты. То же и с пасспортами. Я могу иметь несколько пасспортов различных государств (вполне законно) и все они будут иметь мои разные имена. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 19:03 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
По поводу Вашего второго замечания Можно определить приоритеты во всех (Entities) - как это по-русски не знаю. И обеспечить аттрибут активацию (active - inactive) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 19:07 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
Я сам по себе сторонник ПЕРЕ-страховки и полной нормализации. Де-нормализовывать всегда легче. Поэтому коллега - сделайте полно-нормализованное решение а потом смотрите что меньше всего изменяется - и де-нормализуйте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 19:10 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
MasterZiv, Mr Marmelad мою идею понял, связью многие-ко-многим я хотел показать то, что, например пришел к нам человек в 18 лет подключиться, подключили, все ок... проходит 3 года, он меняет паспорт (по закону положено), но нашим клиентом он не перестает быть, да и договор перезаключаться не хочется, а сведения о ранее выданных паспортах вписываются на отдельной странице, но для истории (мало ли поднимать придется договоры, необходимы его сведения старые, если мы просто изменим паспорт, которым этот человек пользуется, то просто потеряем его данные)... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 20:59 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
Mr Marmelad пишет: > быть зарегистрированы многие клиенты. То же и с пасспортами. Я могу > иметь несколько пасспортов различных государств (вполне законно) и все > они будут иметь мои разные имена. Я ж говорил про 1:N , а не про 1:1. У человека может быть несколько паспортов, но один паспорт не может быть у нескольких человек. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 21:38 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
kuznecov.sg пишет: > что, например пришел к нам человек в 18 лет подключиться, подключили, > все ок... проходит 3 года, он меняет паспорт (по закону положено), но > нашим клиентом он не перестает быть, да и договор перезаключаться не > хочется, а сведения о ранее выданных паспортах вписываются на отдельной > странице, но для истории (мало ли поднимать придется договоры, > необходимы его сведения старые, если мы просто изменим паспорт, которым Вы чё, сговорились ? 1:1 от 1:N отличить не можете ? Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 21:40 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
Ещё один поинт - не сильно характерный для некототрых RDBMS но особенно важен в T-SQL формате (SQL Server). я говорю о местоположении поля в индексе. Особенно в CLUSTER INDEX. Кроме того - это "просто красиво" ;) Коллега - обратите внимание в одном случае у Вас ClientId стоИт на первом месте, в другом посередине в третьем в конце. Перегруппируйте все индексы в порядке селекции (я говорю о [всех] промежуточных табличках) В начало поставьте ClientID (FK to tbl_Clients) а потом ключ второй таблички. это даст Вам большой выигрыш в селекции. Поиск будет упрощён расположением на диске плотно друг другу: . ClientID ClientID ClientID T_1_PK1 T_2_PK1 T_3_PK1 T_1_PK2 T_2_PK2 T_1_PK3 Видите логику? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 21:41 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
MasterZiv, Коллега, Здесь не люди - ЗДЕСЬ Клиенты. Один пасспорт МОЖЕТ быть у двух клиентов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 21:42 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
Если Вы только не собираетесь следить за сутью создания ЧЕЛОВЕКА и КЛИЕНТА ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 21:45 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
Примером будет моя дочь. Я сам стал клиентом и купил пакет моей дочери у которой пасспорта не было с собой ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 21:47 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
Кажется бизнес нашего Коллеги - Инетернет Компания, Ну или телефон (мобильный) что то такое. А вот это то и важно. Пока сам КЛИЕНТ не в состоянии обеспечить свой Пасспорт - за него будет действовать доверенное лице. а потом всё исправится :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 21:50 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
Mr MarmeladЕщё один поинт - не сильно характерный для некототрых RDBMS но особенно важен в T-SQL формате (SQL Server). я говорю о местоположении поля в индексе. Особенно в CLUSTER INDEX. Кроме того - это "просто красиво" ;) ... Спасибо! Я и сам знаю, что неверно, просто мысли другим были заняты, а не приведением в красивый вид табличек. Это сделаю перед деплоем в саму СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 22:23 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
Коллега перед тем когда будете деплоить - подкиньте мне Вашу базу пжст - очень интересно что получится в конце. Идея достойная внимания и детального обсуждения. Для себя Пасспорт я бы заменил на Удостоверение - но это в "за бугром" . У нас все поиски идут по SS#/ FIN - номер социального страхования или Федеральный Такс Айди (корпоративное) который и обеспечивает уникальность каждого клиента. Мы его ставим криптованым атрибутом внутри таблички tbl_Clients. Это к слову как представить привязку к ClientID. Так что пришлите конечный вариант Договорились? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 22:42 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
как вариант - использовать флаг "Текущий/Нет". в таком случае без триггеров не обойтись... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 22:45 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
Mr Marmelad пишет: > Коллега, Здесь не люди - ЗДЕСЬ Клиенты. Один пасспорт МОЖЕТ быть у двух > клиентов Это как ? Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 22:49 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
например я на свой пасспорт и корпоративную кредитку купил подарков всем работникам своей компании. К новому году по мобилке. Всё поставил на счёт компании и дал свой пасспорт как гарант оплаты, Чем не вариант? И теперь мой пасспорт в базе один на 16 клиентов. Через год срок договора кончился и клиента спрашивают - продлевать будем? - Будем. Давай новый пасспорт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 23:01 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
Да забыл предупредить что здесь я не только КЛИЕНТ (для своего номера) а и ГАРАНТОР. Клиентов всего 17 (включая меня) - все мои работники персонализованы со своими адресами и все свои проблемы решают сами. ГАРАНТОР только оплачивает время в течение года. Сами телефоны в случае поломки и ремонта высылаются КЛИЕНТУ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 23:18 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
Кроме того - существуют КОРПОРАТИВНЫЕ клиенты - А они вообще пасспорт используют УСЛОВНО. Так что вариантов Один Пасспорт - Много клиентов очень обширен ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2008, 23:26 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
Mr Marmelad, А такой вопрос: как лучше с этой структурой придумать хранение филиалов (например, есть клиент, у которого разбросанные по городу офисы, с привязанными к ним адресами, номерами телефонов и т.д.)? P.S. Вы угадали - работаю в телекоммуникационной компании ;). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2008, 00:22 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
Mr Marmelad пишет: > например я на свой пасспорт и корпоративную кредитку купил подарков всем > работникам своей компании. К новому году по мобилке. У вас богатая фантазия. Я предлагаю не фантазировать, а отдать это на откуп автору темы. О предметной области мы ничего не знаем. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2008, 00:41 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
Mr Marmelad пишет: > Кроме того - существуют КОРПОРАТИВНЫЕ клиенты - А они вообще пасспорт > используют УСЛОВНО. Тут как с беременностью. Либо используют, либо нет. Очень условно - это используют. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2008, 00:43 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
Ну вообще то если быть предельно аккуратным надо бы в структуру КЛИЕНТА ввести аттрибут Код: plaintext .Филиал (по отношению к головному), Бухгалтерия (все аттрибуты, американские Accounts Payable, Accounts Receivable, Credit Dpt, etc), Налоговые (если есть) отличия, Часы Работы.... Ну и многое другое. В зависимости от специфики Вашего бизнеса это может быть вообще другая БАЗА ДАННЫХ. Это если объём оборота соизмерим (или превышает) с частным сектором. А так - просто учтите внести корпоративные аттрибуты в структуру своих (Entities) Кстати - какой у Вас Модельный Тул? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2008, 00:44 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
MasterZiv О предметной области мы ничего не знаем. Ну уж ТУТ то не надо быть семи пядей во лбу. Тем более что я почти угадал... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2008, 00:46 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
Mr Marmelad...Кстати - какой у Вас Модельный Тул? Sybase PowerDesigner 12 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2008, 00:49 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
MasterZiv Очень условно - это используют. Вот именно - а кто ? Президент? Главбух? Менеджер? А свой аккаунт у него-нее есть? А если есть дочери - у которой нет пасспорта (и пока не было?) Я с Вами абсолютно согласен что это прерогатива бизнеса. Но порой нам следует предположить наиболее вероятностные посылки создания и хранения данных - Так мы будем выглядеть "немного компетентнее" Не правда ли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2008, 00:51 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
kuznecov.sg Sybase PowerDesigner 12 respect!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2008, 00:52 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
MasterZiv Тут как с беременностью. Либо используют, либо нет. Очень условно - это используют. Как раз сейчас читаю "Психбольница в руках пациентов" про психологию разработчиков. Хомо-логикус в корне по-другому представляют работу программы, в отличие от обычных пользователей: "Если есть хотя мельчайшая вероятность наступления какого-либо события - то оно должно быть отражено в коде, в виде исключительной ситуации"... Я, конечно, понимаю, что так и должно быть, но мне необходимо придумать очень гибкую и, в последствии (если придется), расширяемую с минимальными потерями систему. А тут приходится идти на уступки или ухищрения, иначе всех "исключительных ситуаций" не учесть, но без этого не получить гибкости... To Mr Marmelad: Upd. Sybase PowerDesigner под Wine :) (чуть кривовато, но зато работает и лучшего средства визуального проектирования я не нашел, тем более в опен-сорсе). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2008, 00:58 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
В своё время решал подобную задачу. Было два пути - такой же способ как у автора, только с отношением один-ко-многим без промежуточных таблиц. И второй, по которому в итоге пошли. Плясали вот от чего - все изменения в системе должны вноситься на основании соответствующей заявки и быть задокументированы. Т.е. была таблица "заявки" связанная с таблицами Client, таблица ClientHistory (своего рода "выборочная" копия инфы по клиенту) . При добавлении новой заявки, требующей изменения клиентской информации, вся информация по клиенту, требующая изменения, уходила в архивную таблицу(естественно с датой изменения и ClientID), а в таблицу Client сохранялась актуальная. Сейчас уже не вспомню, почему пошли именно по этому варианту. Но тогда были какие-то весомые аргументы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2008, 09:19 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
Ну уж если нормализовывать до конца, то таблицу адресов тоже надо разбивать. Хранить не названия улиц, регионов и т.д., а как-то типо того: автор tbl_adresses ........ region_id int street_id int ......... tbl_street street_id int street_Name varchar ........... tbl_region region_id int region_Name varchar .......... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2008, 09:38 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
Можно добавитьНу уж если нормализовывать до конца, то таблицу адресов тоже надо разбивать. Хранить не названия улиц, регионов и т.д., а как-то типо того: Так и делают но в случае если бизнес связан с Недвижимостью. В реальной жизни когда региональное изменение клиента "не предвидится" или "очень редко" таких крайностей мы не допускаем. Считайте это началом ДЕ-нормализации. Потом может быть двойственность табличек в корпоративной части бизнеса. Потом может воссоединение всех аттрибутов таблички ПАССПОРТ с табличкой КЛИЕНТ - ведь по сути пасспортные изменения исторически не влияют на ход действия. Ну был один пасспорт, ну стал другой - и что? Главное чтобы была ОБЯЗАТЕЛЬНАЯ связь ОДНОГО КЛИЕНТА с ОДНИМ ПАССПОРТОМ. Но это всё будет потом. А пока - без крайности на нормализацию адресов - отличное начало. Кстати - ДЕ-нормализация всегда необходима. но только ПОСЛЕ разумной нормализации ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2008, 16:28 |
|
||
|
Помогите найти верное решение для структуры
|
|||
|---|---|---|---|
|
#18+
есть такое предложение (на примере адреса клиента): в табличке адрес создать поля DateBegin, DateEnd и если клиент переехал на новый адрес, а на старый адрес приехал другой клиент, то другому клиенту заводится новый идентификатор адреса, а тот адрес "забывается" навсегда. Либо если надо искать клиентов на одном адресе, то можно такую схему организовать через промежуточную табличку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2008, 14:17 |
|
||
|
|

start [/forum/topic.php?all=1&fid=32&tid=1543574]: |
0ms |
get settings: |
7ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
181ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
| others: | 238ms |
| total: | 493ms |

| 0 / 0 |
