|
авторНе так. Я говорил про различные типы значений аттрибута Адрес. Который есть един и неделим. )
Например, один специалист должен хранить формат Адрес, скажем в текстовой строке, без выделения, скажем улицы, дома, корпуса, офиса, и индекса. А другому нужно это выделение.. А у третьего, это вообще выбор из справочника адресов..
Или еще, вот есть аттрибут "Дата начала": один хранит его в формате time_t, а другому нужно "23-AUG-2008 23:53:53".. Все это конечно можно привести к time_t и потом приводить к необходимому виду. Просто, я хочу сказать что из этого всего следует, что форматы значений аттрибутов - разные. Как и кол-во аттрибутов и их набор на объект, как и кол-во объектов. Вот что имелось ввиду.
раньше нельзя было это сказать? Как вы ТЗ составляете? Или задачи ставите?
- "один специалист" в условиях многопользовательской системы - это функциональное рабочее место ФРМ "Спец".
Представим ВИ данного ФРМ №1:
- вводит новый атрибут "адрес"
- проверяет наличие уже данного атрибута у сервиса №12345
а)- у данного сервиса нет атрибута
б)- у данного сервиса есть атрибут, но с форматом Строка (нам нужен справочник (дом, квартал, улица, корпус...))
как вы представляете (нужно вашему бизнесу) дальнейшие действия?
ААААААААА. (Пишите Вы кучеряво). Вы имелли ввиду не форматы разные, а формат хранения в БД один, а формат ПРЕДСТАВЛЕНИЯ для каждого ФРМ различный?
Т.е. для логина Иван Иваныч адрес будет склеенная строка, а для Петра Петровича - код улицы, номер дома и т.д.?
Приведите реальный пример реального длинного адреса:
- хранящегося в БД
- показываемого всем(каждому) пользователю
ЗЫ Формат хранения и формат представления - разные вещи.
авторЧто именно не понятно? Вроде понятно, что после созданий объекта
==== на клиенте? Понятно.
, и привязки к нему набора аттрибутов
======== непонятно. Я хоть и программист, но термин привязка ПОЛЬЗОВАТЕЛЕМ непонятна. НАПИШИТЕ ВИ (вариант использования)
, создается статическая таблица
=== нет такого понятия в оракле и других бд. Будем считать ОБЫЧНАЯ
, которая есть этот объект, с полями, которые есть эти аттрибуты.
=======
1.1.1.1 Суть подхода «Класс как таблица (ROT)»
Аттрибуты, есть многомерная таблица (z-ось, есть описание формата данного аттрибута для данного пользователя), из которой выбирается необходимый данному пользователю аттрибут. Далее, после автоматического создания данной таблицы, создаются необходимые PK/FK/indexes/triggers связанные с этой таблицей. Все эти аттрибуты таблицы создаются так-же автоматически. Далее, на сервере приложений мы с помощью обычных sql запросов получаем необходимые данные из этой таблицы. Т.е., например, мы ищем необходимые данные по аттрибуту "Адрес", объекта "Рестораны". Мы сначала ищем, наименование таблицы описывающей объект "Рестораны" в таблице объектов. Далее, мы ищем наименование поля, описывающего аттрибут "Адрес".
======= т.е.
Таблица_Иванова
Ресторан Адрес Field_Adress
Далее, по таблице-объекту и полю-аттрибуту ищем адрес, причем, в формате для данного пользователя (табл. аттрибутов - многомерна). Т.е., кому-то адрес - это обычная текстовая строка. Кто-то содержит адрес в виде форматированной текстовой строки (для разбиения ее на улицу, дом, корпус, офис, и т.д. Кто-то, указатель на справочник адресов.
====== тоже в динамике пользователем Иван Иваныч? И что такое указатель в РСУБД? FK?
Соответственно, в UI, у одного пользователя возникает обычный текстовый input. У другого уже несколько текстовых inputов, а у третьего select со списком адресов. И получают они таблицу, с записями по объекту "Рестораны", с выбранным ранее списком аттриботов (полей таблицы-объекта), и содержащим необходимые данные в аттрибуте "Адрес"..
Конечно, из этого следует что таблиц-объектов "Рестораны", будет <= кол-ву пользователей имеющих право создавать объекты и аттрибуты..
Постарайте прочесть текст из этого абзаца выше, не по диагонали. И вы достигните просветления.. )
нда! прочёл 8-)
IMHO
- этот абзац на форум по Проектированию БД, там тебе скажут более профессионально про многомерные таблицы и Z ось в БД
- перед этим определиться в ВИ, и в текстовом виде ЗДЕСЬ написать КАК БУДЕТ РАБОТАТЬ ИВАН ИВАНЫЧ со всей этой байдой
- перед этим определиться в ВИ, и в текстовом виде ЗДЕСЬ написать КАК БУДЕТ РАБОТАТЬ ПЕТР ПЕТРОВИЧ делая поиск по всей этой массе разнородной-разноформатой инфы
- пример ВИ я написал выше
IMHO
- У Вас в работе нет ни одного ограничения
- Вы на пользователя хотите повесить (хоть и в автомате) создание объектов, атрибутов, ссылок на справочник, заполнение справочников, создание триггеров, FK и тд., определение типа атрибута. Какая зарплата у данного пользователя?
- система а-ля 1С хороша, но у меня жена глав-бух не сама там программирует и вводит атрибуты, а меня зовёт :).
- доработка данной системы в процессе эксплуатации будет неглюкавее, дешевле и быстрее
авторА я лишь пытаюсь разработать наиболее удачную архитектуру
- займитесь ВИ, в паре с разработчиком БД (они в другом форуме сидят)
______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!
|
