powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Помогите найти верное решение для структуры
36 сообщений из 36, показаны все 2 страниц
Помогите найти верное решение для структуры
    #35647239
kuznecov.sg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Здравствуйте!

Такая проблема при проектировании БД, на приложенном рисунке часть таблиц, завязанных на главной таблице tbl_clients.
Необходимо каждый атрибут со связями многие-ко-многим (например, несколько различных адресов у клиента, или несколько контактных телефонов) хранить во взяимосвязи с его временем действия (т.е. как бы хранить историю изменений (например, при переезде клиента у него сменился адрес, но мне нужно знать всего его адреса для истории).
Наиболее простым решением мне показалось объединение атрибутов через промежуточные таблицы, которые по каждой записи будут хранить и время ее действия.
Верно ли это? Такое чувство, что база получается ненормализованной.
У меня такое чувство, что я что-то неверно делаю, но с другой стороны мне кажется верным такое решение... В общем, я запутался.
Что делать? Правильное это решение или нет?.. Если нет, то в какую сторону "копать"?
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35647304
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Единственное замечание (персонально моё) - Имя клиента тоже может меняться. Неразумно его аттрибутом в Вашем Универсальном Блоке держать. А вообще - вполне логичное и главное - интересное решение.
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35647339
kuznecov.sg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Mr Marmelad,

А имя (которое shortName и fullName в основной таблице клиентов), в этой таблице - не основное, просто справочное, при выставлении счетов и т.п. будут выбираться обязательно из других таблиц. Эти поля скорее для менеджеров отдела продаж нужны.
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35647368
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если так - то мой вердикт - Очень Положительно
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35647617
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kuznecov.sg пишет:

> Такая проблема при проектировании БД, на приложенном рисунке часть

Я вот не понял 2 вещи:

-- у вас Клиент к (например) адресу относится как многие-ко-многим.
Это зачем ? Я не знаю, может это и нужно, но в принципе обычно делают
Клиент к адресу (или ещё чему-то) как один-ко-многим. Потому что
вам нет смысла (обычно) отслеживать, живут ли 10 ваших клиентов
в одном месте. Если есть - то на здоровье, конечно.
Но вот с паспортом вы кажется совсем уже перемудрили - один
паспорт двум людям вроде бы не выдают. У вас - вроде можно
(там картинка обрезана, не видно точно).
Наверное, надо с этим разобраться.

-- Второе (вытекает из первого). Допустим, что да, вам
там действительно нужно многие-ко-многим. Тогда решите,
период действия ЧЕГО вы храните в вашей БД ?
Давайте рассмотрим на примере телефона.
Телефон сам по себе может быть аннулирован. Был телефон -
и сняли. Или там была SIM-карта - растроргли договор.
Это - один аспект. Кроме этого, вы говорите у себя в БД:
"мой клиент такой-то доступен по такому телефону".
"мой клиент Другой доступен по тому же телефону".
Далее, проходит время, и первый клиент перестаёт быть
доступен по этому телефону. А второй - остаётся.

Соответственно, решите, что вам надо, и либо убейте многие-ко-многим,
оставив один-ко-многим, и перенесите период в часть "многие" (в атрибут),
либо оставьте многие-ко-многим, но решите, где быть периоду:
-- в связи
-- в атрибуте
-- и там, и там. (кажется такое очень избыточно, но кто вас знает что там вам надо).

И последнее (отдельное зам.). Кажется контакты (contactID где)
могут быть либо e-mail, либо сайт. Я бы сделал разные виды
контактов (кстати туда и телефон, и почтовый адрес можно добавить),
и их бы связывал - у вас всё равно же многие-ко-многим.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35647639
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот Тут я с коллегой MasterZiv не совсем согласен. Позвольте высказать своё мнение. Не знаю законов вашего бизнеса коллега. Но

И адреса и пасспорта вполне могут иметь разбивку Много - Много. Одит и тот же клиент может имень разные адреса и имена И на одном адресе могут быть зарегистрированы многие клиенты. То же и с пасспортами. Я могу иметь несколько пасспортов различных государств (вполне законно) и все они будут иметь мои разные имена.
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35647647
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
По поводу Вашего второго замечания Можно определить приоритеты во всех (Entities) - как это по-русски не знаю. И обеспечить аттрибут активацию (active - inactive)
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35647649
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я сам по себе сторонник ПЕРЕ-страховки и полной нормализации. Де-нормализовывать всегда легче. Поэтому коллега - сделайте полно-нормализованное решение а потом смотрите что меньше всего изменяется - и де-нормализуйте.
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35647808
kuznecov.sg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
MasterZiv,

Mr Marmelad мою идею понял, связью многие-ко-многим я хотел показать то, что, например пришел к нам человек в 18 лет подключиться, подключили, все ок... проходит 3 года, он меняет паспорт (по закону положено), но нашим клиентом он не перестает быть, да и договор перезаключаться не хочется, а сведения о ранее выданных паспортах вписываются на отдельной странице, но для истории (мало ли поднимать придется договоры, необходимы его сведения старые, если мы просто изменим паспорт, которым этот человек пользуется, то просто потеряем его данные)...
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35647851
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Mr Marmelad пишет:

> быть зарегистрированы многие клиенты. То же и с пасспортами. Я могу
> иметь несколько пасспортов различных государств (вполне законно) и все
> они будут иметь мои разные имена.

Я ж говорил про 1:N , а не про 1:1. У человека может быть несколько
паспортов, но один паспорт не может быть у нескольких человек.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35647854
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kuznecov.sg пишет:

> что, например пришел к нам человек в 18 лет подключиться, подключили,
> все ок... проходит 3 года, он меняет паспорт (по закону положено), но
> нашим клиентом он не перестает быть, да и договор перезаключаться не
> хочется, а сведения о ранее выданных паспортах вписываются на отдельной
> странице, но для истории (мало ли поднимать придется договоры,
> необходимы его сведения старые, если мы просто изменим паспорт, которым

Вы чё, сговорились ? 1:1 от 1:N отличить не можете ?
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35647855
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ещё один поинт - не сильно характерный для некототрых 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

Видите логику?
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35647856
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv,


Коллега, Здесь не люди - ЗДЕСЬ Клиенты. Один пасспорт МОЖЕТ быть у двух клиентов
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35647858
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если Вы только не собираетесь следить за сутью создания ЧЕЛОВЕКА и КЛИЕНТА
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35647861
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Примером будет моя дочь. Я сам стал клиентом и купил пакет моей дочери у которой пасспорта не было с собой
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35647868
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кажется бизнес нашего Коллеги - Инетернет Компания, Ну или телефон (мобильный) что то такое. А вот это то и важно. Пока сам КЛИЕНТ не в состоянии обеспечить свой Пасспорт - за него будет действовать доверенное лице. а потом всё исправится :)
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35647897
kuznecov.sg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Mr MarmeladЕщё один поинт - не сильно характерный для некототрых RDBMS но особенно важен в T-SQL формате (SQL Server). я говорю о местоположении поля в индексе. Особенно в CLUSTER INDEX. Кроме того - это "просто красиво" ;) ...

Спасибо! Я и сам знаю, что неверно, просто мысли другим были заняты, а не приведением в красивый вид табличек. Это сделаю перед деплоем в саму СУБД.
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35647908
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Коллега перед тем когда будете деплоить - подкиньте мне Вашу базу пжст - очень интересно что получится в конце. Идея достойная внимания и детального обсуждения. Для себя Пасспорт я бы заменил на Удостоверение - но это в "за бугром" . У нас все поиски идут по SS#/ FIN - номер социального страхования или Федеральный Такс Айди (корпоративное) который и обеспечивает уникальность каждого клиента. Мы его ставим криптованым атрибутом внутри таблички tbl_Clients. Это к слову как представить привязку к ClientID. Так что пришлите конечный вариант Договорились?
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35647910
freestyle
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
как вариант - использовать флаг "Текущий/Нет". в таком случае без триггеров не обойтись...
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35647915
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Mr Marmelad пишет:

> Коллега, Здесь не люди - ЗДЕСЬ Клиенты. Один пасспорт МОЖЕТ быть у двух
> клиентов

Это как ?
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35647929
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
например я на свой пасспорт и корпоративную кредитку купил подарков всем работникам своей компании. К новому году по мобилке. Всё поставил на счёт компании и дал свой пасспорт как гарант оплаты, Чем не вариант? И теперь мой пасспорт в базе один на 16 клиентов. Через год срок договора кончился и клиента спрашивают - продлевать будем? - Будем. Давай новый пасспорт.
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35647951
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да забыл предупредить что здесь я не только КЛИЕНТ (для своего номера) а и ГАРАНТОР. Клиентов всего 17 (включая меня) - все мои работники персонализованы со своими адресами и все свои проблемы решают сами. ГАРАНТОР только оплачивает время в течение года. Сами телефоны в случае поломки и ремонта высылаются КЛИЕНТУ.
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35647960
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кроме того - существуют КОРПОРАТИВНЫЕ клиенты - А они вообще пасспорт используют УСЛОВНО. Так что вариантов Один Пасспорт - Много клиентов очень обширен
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35648018
kuznecov.sg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Mr Marmelad,

А такой вопрос: как лучше с этой структурой придумать хранение филиалов (например, есть клиент, у которого разбросанные по городу офисы, с привязанными к ним адресами, номерами телефонов и т.д.)?
P.S. Вы угадали - работаю в телекоммуникационной компании ;).
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35648036
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Mr Marmelad пишет:
> например я на свой пасспорт и корпоративную кредитку купил подарков всем
> работникам своей компании. К новому году по мобилке.

У вас богатая фантазия. Я предлагаю не фантазировать, а отдать это
на откуп автору темы. О предметной области мы ничего не знаем.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35648038
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Mr Marmelad пишет:

> Кроме того - существуют КОРПОРАТИВНЫЕ клиенты - А они вообще пасспорт
> используют УСЛОВНО.

Тут как с беременностью. Либо используют, либо нет. Очень условно - это
используют.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35648041
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну вообще то если быть предельно аккуратным надо бы в структуру КЛИЕНТА ввести аттрибут
Код: plaintext
IsCorporate BOOL
. Тогда нормализация будет затрагивать немного другой набор табличек. Пусть даже поначалу они будут дублировать структуру общую. Там зато и будут сугубо КОРПОРАТИВНЫЕ аттрибуты например

.Филиал (по отношению к головному),
Бухгалтерия (все аттрибуты, американские Accounts Payable, Accounts Receivable, Credit Dpt, etc),
Налоговые (если есть) отличия,
Часы Работы....

Ну и многое другое. В зависимости от специфики Вашего бизнеса это может быть вообще другая БАЗА ДАННЫХ. Это если объём оборота соизмерим (или превышает) с частным сектором. А так - просто учтите внести корпоративные аттрибуты в структуру своих (Entities) Кстати - какой у Вас Модельный Тул?
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35648042
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv
О предметной области мы ничего не знаем.


Ну уж ТУТ то не надо быть семи пядей во лбу. Тем более что я почти угадал...
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35648046
kuznecov.sg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Mr Marmelad...Кстати - какой у Вас Модельный Тул?

Sybase PowerDesigner 12
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35648048
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv
Очень условно - это используют.


Вот именно - а кто ? Президент? Главбух? Менеджер? А свой аккаунт у него-нее есть? А если есть дочери - у которой нет пасспорта (и пока не было?) Я с Вами абсолютно согласен что это прерогатива бизнеса. Но порой нам следует предположить наиболее вероятностные посылки создания и хранения данных - Так мы будем выглядеть "немного компетентнее" Не правда ли?
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35648050
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kuznecov.sg
Sybase PowerDesigner 12

respect!!!
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35648056
kuznecov.sg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
MasterZiv
Тут как с беременностью. Либо используют, либо нет. Очень условно - это используют.


Как раз сейчас читаю "Психбольница в руках пациентов" про психологию разработчиков. Хомо-логикус в корне по-другому представляют работу программы, в отличие от обычных пользователей: "Если есть хотя мельчайшая вероятность наступления какого-либо события - то оно должно быть отражено в коде, в виде исключительной ситуации"... Я, конечно, понимаю, что так и должно быть, но мне необходимо придумать очень гибкую и, в последствии (если придется), расширяемую с минимальными потерями систему. А тут приходится идти на уступки или ухищрения, иначе всех "исключительных ситуаций" не учесть, но без этого не получить гибкости...

To Mr Marmelad: Upd. Sybase PowerDesigner под Wine :) (чуть кривовато, но зато работает и лучшего средства визуального проектирования я не нашел, тем более в опен-сорсе).
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35648228
Micola_mgn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
В своё время решал подобную задачу. Было два пути - такой же способ как у автора, только с отношением один-ко-многим без промежуточных таблиц. И второй, по которому в итоге пошли.
Плясали вот от чего - все изменения в системе должны вноситься на основании соответствующей заявки и быть задокументированы. Т.е. была таблица "заявки" связанная с таблицами Client, таблица ClientHistory (своего рода "выборочная" копия инфы по клиенту) . При добавлении новой заявки, требующей изменения клиентской информации, вся информация по клиенту, требующая изменения, уходила в архивную таблицу(естественно с датой изменения и ClientID), а в таблицу Client сохранялась актуальная.
Сейчас уже не вспомню, почему пошли именно по этому варианту. Но тогда были какие-то весомые аргументы
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35648267
Ну уж если нормализовывать до конца, то таблицу адресов тоже надо разбивать. Хранить не названия улиц, регионов и т.д., а как-то типо того:
автор
tbl_adresses
........
region_id int
street_id int
.........



tbl_street
street_id int
street_Name varchar
...........


tbl_region
region_id int
region_Name varchar
..........
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35649728
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Можно добавитьНу уж если нормализовывать до конца, то таблицу адресов тоже надо разбивать. Хранить не названия улиц, регионов и т.д., а как-то типо того:

Так и делают но в случае если бизнес связан с Недвижимостью. В реальной жизни когда региональное изменение клиента "не предвидится" или "очень редко" таких крайностей мы не допускаем. Считайте это началом ДЕ-нормализации. Потом может быть двойственность табличек в корпоративной части бизнеса. Потом может воссоединение всех аттрибутов таблички ПАССПОРТ с табличкой КЛИЕНТ - ведь по сути пасспортные изменения исторически не влияют на ход действия. Ну был один пасспорт, ну стал другой - и что? Главное чтобы была ОБЯЗАТЕЛЬНАЯ связь ОДНОГО КЛИЕНТА с ОДНИМ ПАССПОРТОМ. Но это всё будет потом. А пока - без крайности на нормализацию адресов - отличное начало.

Кстати - ДЕ-нормализация всегда необходима. но только ПОСЛЕ разумной нормализации
...
Рейтинг: 0 / 0
Помогите найти верное решение для структуры
    #35651774
vinger4
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
есть такое предложение (на примере адреса клиента):
в табличке адрес создать поля DateBegin, DateEnd и если клиент переехал на новый адрес, а на старый адрес приехал другой клиент, то другому клиенту заводится новый идентификатор адреса, а тот адрес "забывается" навсегда. Либо если надо искать клиентов на одном адресе, то можно такую схему организовать через промежуточную табличку.
...
Рейтинг: 0 / 0
36 сообщений из 36, показаны все 2 страниц
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Помогите найти верное решение для структуры
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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