ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Помогите найти верное решение для структуры
11 сообщений из 36, страница 2 из 2
  2  все
Помогите найти верное решение для структуры
    #35648038
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Mr Marmelad пишет:

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

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

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

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


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

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


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

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


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

To Mr Marmelad: Upd. Sybase PowerDesigner под Wine :) (чуть кривовато, но зато работает и лучшего средства визуального проектирования я не нашел, тем более в опен-сорсе).
...
Рейтинг: 0 / 0
12.11.2008, 00:58
| Ответить | Цитировать | Написать  
Помогите найти верное решение для структуры
    #35648228
Micola_mgn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Micola_mgn
Гость
В своё время решал подобную задачу. Было два пути - такой же способ как у автора, только с отношением один-ко-многим без промежуточных таблиц. И второй, по которому в итоге пошли.
Плясали вот от чего - все изменения в системе должны вноситься на основании соответствующей заявки и быть задокументированы. Т.е. была таблица "заявки" связанная с таблицами Client, таблица ClientHistory (своего рода "выборочная" копия инфы по клиенту) . При добавлении новой заявки, требующей изменения клиентской информации, вся информация по клиенту, требующая изменения, уходила в архивную таблицу(естественно с датой изменения и ClientID), а в таблицу Client сохранялась актуальная.
Сейчас уже не вспомню, почему пошли именно по этому варианту. Но тогда были какие-то весомые аргументы
...
Рейтинг: 0 / 0
12.11.2008, 09:19
| Ответить | Цитировать | Написать  
Помогите найти верное решение для структуры
    #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
12.11.2008, 09:38
| Ответить | Цитировать | Написать  
Помогите найти верное решение для структуры
    #35649728
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
Можно добавитьНу уж если нормализовывать до конца, то таблицу адресов тоже надо разбивать. Хранить не названия улиц, регионов и т.д., а как-то типо того:

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

Кстати - ДЕ-нормализация всегда необходима. но только ПОСЛЕ разумной нормализации
...
Рейтинг: 0 / 0
12.11.2008, 16:28
| Ответить | Цитировать | Написать  
Помогите найти верное решение для структуры
    #35651774
vinger4
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vinger4
Гость
есть такое предложение (на примере адреса клиента):
в табличке адрес создать поля DateBegin, DateEnd и если клиент переехал на новый адрес, а на старый адрес приехал другой клиент, то другому клиенту заводится новый идентификатор адреса, а тот адрес "забывается" навсегда. Либо если надо искать клиентов на одном адресе, то можно такую схему организовать через промежуточную табличку.
...
Рейтинг: 0 / 0
13.11.2008, 14:17
| Ответить | Цитировать | Написать  
11 сообщений из 36, страница 2 из 2
  2  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Помогите найти верное решение для структуры
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&startmsg=35648038&tid=1543574]:
 0ms
get settings:
 9ms
get forum list:
 18ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 140ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 53ms
get tp. blocked users:
 1ms
others: 208ms
total:  447ms
созд. / загр.: 447ms
x
x
Закрыть


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