Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

Хранение разнородных данных для однородных объектов

263
22 декабря 2008 года
koltaviy
816 / / 16.12.2004
Всем привет.
Ситуация следующая:
1) Существуют клиенты-пользователи СУБД. Таблица и поля для хранения данных по ним определены.
2) Пользователи работают с СУБД. Им, в свою очередь, необходимио хранить данные по своим клиентам.
Ситуация усложняется тем, что разные контрагенты хотят хранить различные данные по своим клиентам. К примеру, автоцентр захочет хранить данные о купленном автомобиле, а салон красоты - данные о цвете волос клиента (в порядке бреда ;)).
К примеру, при появлении новой потребности, я создаю ряд доп. таблиц для хранения информации о приобретенном автомобиле. Также делаю соответствуюшие модификации для хранения цвета волос клиента. С этим проблем нет.
Вопрос следующий:
Как при входе соответствующего пользователя в систему определить какими данными он будет пользоваться. Предоставить данные для просмотра, изменения и т.д..
Другие варианты построения такой системы тоже рассматриваются. Заранее спасибо за участие в обсуждении.
11
22 декабря 2008 года
oxotnik333
2.9K / / 03.08.2007
в самом простом варианте таблица пользователей к ней таблица клиентов (один ко многим) к последней таблица характеристик (один ко многим)
т.о. на каждую единицу можно настроить свои характеристики, если нужен шаблон характеристик, тогда ввести промежуточную таблицу, в которой описать эти шаблоны.
263
22 декабря 2008 года
koltaviy
816 / / 16.12.2004
Цитата: oxotnik333
в самом простом варианте таблица пользователей к ней таблица клиентов (один ко многим) к последней таблица характеристик (один ко многим)
т.о. на каждую единицу можно настроить свои характеристики, если нужен шаблон характеристик, тогда ввести промежуточную таблицу, в которой описать эти шаблоны.


Как хранить данные - это понятно.
Что есть "шаблон характеристик"??
Поясню.

Juridicals: ID, Login, Password
Data:
1 - AutoUser - 123
2 - BeautyUser - 321

Naturals: ID, Name, DateOfBirth, Gender
Data:
1 - Ivanov - 01/12/1986 - 0
2 - Petrova - 02/12/1985 - 1

JuridicalsClients: ID, Juridicals_ID, Naturals_ID
Data:
1 - 1 - 1
2 - 1 - 2
3 - 2 - 1

AutoFactories: ID, Name
Data:
1 - Subaru
2 - Hundai

AutoModels: ID, AutoFactories_ID, Name
Data:
1 - 1 - Forester
2 - 1 - Impreza

HairColours: ID, Name
Data:
1 - Blonde
2 - Red
3 - Brown

NaturalsHairColours: ID, Naturals_ID, HairColours_ID
Data:
1 - 1 - 1

NaturalsAutos: ID, Naturals_ID, AutoModels_ID, BoughtDate
Data:
1 - 1 - 1 - 5/12/2008
2 - 1 - 2 - 5/12/2008
3 - 2 - 2 - 12/12/2008

Вот такая ситуация. И что мне делать дальше?? Создать еще одну таблицу JuridicalsTypes и поле в таблице Juridicals [JuridicalsTypes_ID]?? Так??
А дальше как?? Т.е. получается нужно описывать правила на программном уровне - что именно отображать для каждого типа юр. лица?? И при добавление нового типа клиента, лезть не только в БД с добавлением новых полей, таблиц, запросов и т.д., но и в программный код?? Кривенько как-то это всё. Если учесть еще, что один автосалон захочет хранить данные о покупке, а второй еще, к примеру, данные о скидках. Хотелось бы красивого решения. Не думаю что задача нова.

Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог