ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование атомарных справочников...
25 сообщений из 325, страница 10 из 13
  10  все
Проектирование атомарных справочников...
    #38548250
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
_модguest_20040621 Задача тривиальнейшая: контекстно-зависимый справочник.
А можно уточнить - что это такое ? Тогда и решение будет.Не знаете, что это такое ??? Бывает.... :)
Если упрощенно, то: Это когда на список допустимых значений накладывается некий фильтр в завис. от свойств главной сущности.
Пример ? Дык был же уже. Цвет автомобиля. В завис. от марки набор возможных цветов или даже их оригинальных названий (ментол, графит, молочный, асфальт, белая ночь и т.п.).
Даже красный корпоративный цвет кока-колы имеет специальное название (н-р для рекламистов).

зы: Усложнить задачу КЗС можно до бесконечности.
...
Рейтинг: 0 / 0
04.02.2014, 11:38
| Ответить | Цитировать | Написать  
Проектирование атомарных справочников...
    #38548274
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
LSV_модпропущено...

А можно уточнить - что это такое ? Тогда и решение будет.Не знаете, что это такое ??? Бывает.... :)
Если упрощенно, то: Это когда на список допустимых значений накладывается некий фильтр в завис. от свойств главной сущности.
Пример ? Дык был же уже. Цвет автомобиля. В завис. от марки набор возможных цветов или даже их оригинальных названий (ментол, графит, молочный, асфальт, белая ночь и т.п.).
Даже красный корпоративный цвет кока-колы имеет специальное название (н-р для рекламистов).

Ну а чего тут сложного-то?
(я, кстати, при словосочетании "контекстно зависимый справочник" совсем другую вещь представил - значение атрибута "цвет",
которое в одном отчете выводится как "серый N21", в другом - "светлый", в третьем "Белая ночь").
...
Рейтинг: 0 / 0
04.02.2014, 11:54
| Ответить | Цитировать | Написать  
Проектирование атомарных справочников...
    #38548303
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
LSVЕсли упрощенно, то: Это когда на список допустимых значений накладывается некий фильтр в завис. от свойств главной сущности.
Примитивный фильтр на уровне UI. Придумайте что-нибудь поинтереснее.
...
Рейтинг: 0 / 0
04.02.2014, 12:07
| Ответить | Цитировать | Написать  
Проектирование атомарных справочников...
    #38548307
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
Кот Матроскин(я, кстати, при словосочетании "контекстно зависимый справочник" совсем другую вещь представил - значение атрибута "цвет",
которое в одном отчете выводится как "серый N21", в другом - "светлый", в третьем "Белая ночь").
Контекстно зависимые сисонимы. Посложнее будет, но тоже решаемо.
...
Рейтинг: 0 / 0
04.02.2014, 12:10
| Ответить | Цитировать | Написать  
Проектирование атомарных справочников...
    #38548343
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Ну а чего тут сложного-то?

Ничего. Громоздко несколько. Но в данном случае интерес представляет не реализация, а требования к справочникам, которые она предполагает. У каждой сущности - от стандартов до состава контекста - свой жизненный цикл.

> значение атрибута "цвет", которое в одном отчете выводится как "серый N21", в другом - "светлый", в третьем "Белая ночь"

Соответствия - связанная задача. Хороший, кстати, пример: "светлый" нельзя корректно сопоставить значению цвета.
...
Рейтинг: 0 / 0
04.02.2014, 12:20
| Ответить | Цитировать | Написать  
Проектирование атомарных справочников...
    #38548416
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
guest_20040621 Хороший, кстати, пример: "светлый" нельзя корректно сопоставить значению цвета.

Конечно. Если все значения-синонимы соспоставляются 1:1, то задача тривиальна - оператор ставит любой из синонимов, а система дальше разбирается, что где показывать. А вот если нет - то проблема даже не в структуре таблиц, а в организации удобного заполнения этого поля для оператора.
...
Рейтинг: 0 / 0
04.02.2014, 12:51
| Ответить | Цитировать | Написать  
Проектирование атомарных справочников...
    #38548475
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Конечно

Дело не только в этом. Диапазоны, сегменты - понятно. Светлый - может быть характеристика, например, пива, - здесь цвет как таковой роли не играет.
...
Рейтинг: 0 / 0
04.02.2014, 13:16
| Ответить | Цитировать | Написать  
Проектирование атомарных справочников...
    #38550324
Жертва единого справочника.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Жертва единого справочника.
Гость
Тока что разбирался с кодом запроса, использующего метОду единого справочника. Ужас. Запрос работает дико медленно.
...
Рейтинг: 0 / 0
05.02.2014, 14:38
| Ответить | Цитировать | Написать  
Проектирование атомарных справочников...
    #38553960
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
Жертва единого справочника.Тока что разбирался с кодом запроса, использующего метОду единого справочника. Ужас. Запрос работает дико медленно.

А я, третьего дня, по дороге на работу накрутил какую-то радиостанцию, так там такая музыка была, что мне вообще не понравилось. Аж настроение на целый день испортилось. Случаем не знаете композитора этой гадости?

Код запроса в студию, а то может статься, что жертва не Вы , а ни в чём не повинный справочник.
...
Рейтинг: 0 / 0
07.02.2014, 18:18
| Ответить | Цитировать | Написать  
Проектирование атомарных справочников...
    #38554155
Sgt.Pepper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sgt.Pepper
Участник
GoffmanSgt.Pepperпропущено...
А заказчика интересуют собственные интересы...
Что из ЭТОГО следует?...
Как минимум, что у разработчика зачастую нет интереса создавать для заказчика качественное и масштабируемое решение, и в этом смысле становится понятным его стремление увеличить скорость разработки за счет отступления от классических правил построения БД.В который раз прошу Вас озвучить отступление от классических правил РМД.
Эдвард Кодд сказал, что связи реализуются только через FK?..

Если он такого не говорил, то "скорость разработки", "качественное и масштабируемое" решение или финансовые дивиденды участников сделки следует рассматривать в плоскости целесообразности, удобства и т.д., но, возможно, существующие в рамках парадигмы РМД ...

Вы, как я понимаю, готовы доказать в случае объединенного справочника конфликт с моделью (с моделью!)...
...
Рейтинг: 0 / 0
07.02.2014, 22:31
| Ответить | Цитировать | Написать  
Проектирование атомарных справочников...
    #38554172
Sgt.Pepper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sgt.Pepper
Участник
GoffmanВ теории РБД нет так же понятия атомарный и объединенный справочник, но это почему то вас не смущает.
Понятие "ссылочное поле" я использовал намеренно, т.к. в круг обсуждаемых систем входят системы c FK и без FK.С чего это должно меня смущать, если назови его хоть объединенным, хоть совмещенным, хоть атомарным, он м.б. реализован отношением в контексте РМД?...
А в Ваших "связях" и "ссылках" есть некие допущения, которые сужают РМД (уж не знаю - по недомыслию или упертости).
У Вас зацикленность на FK...
FK - это вырожденная "связь" (или "ссылка" или как еще ни назовите)...
В общем случае для "связи" или "ссылки" FK является необходимым условием, но недостаточным, если "связь" или "ссылка" реализована классически, через отношения.

GoffmanНу например, у нас есть каталог обуви, и нам понадобилось добавить классификацию по цвету. Что нам нужно сделать?
1. создать классификатор цветов (неважно в отдельной таблице или в объединенном справочнике)
2. создать в "таблице обуви" атрибут "цвет" - который будет ссылаться на классификатор "цвет"
3. создать в UI контрол, который будет обслуживать атрибут "цвет обуви"Вдумайтесь еще раз , что п.2 в общем случае с точки зрения РМД - совсем не обязательный, а как следствие и п.3...

ps
Вас не смущает, что даже такие радикалы, как guest_XXXXX, не оспаривают соответствия РМД, а утверждают, что так проектируют только долбо^ебы?...
И я с этим утверждением в общем согласен - у этого подхода есть очень ограниченная область применения, но я возражаю, что:
- он требует "патчей", изменения схемы и внедрения...
- его не следует применять никогда...

Даже такой касатка проектирования жизни ртом как guest_XXXXX сознался, что подход м.б. применим для "переходных процессов", которые впоследствии следует реализовывать классическим образом...
...
Рейтинг: 0 / 0
07.02.2014, 23:07
| Ответить | Цитировать | Написать  
Проектирование атомарных справочников...
    #38554239
Sgt.Pepper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sgt.Pepper
Участник
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
CREATE TABLE Country
(
	country_id int NOT NULL,
	country_name varchar(50) NULL,
 CONSTRAINT PK_Country PRIMARY KEY CLUSTERED 
(
	country_id
)

CREATE TABLE Dictionary
(
	dict_id int NOT NULL,
	dict_name varchar(50) NULL,
 CONSTRAINT PK_Dictionary PRIMARY KEY CLUSTERED 
(
	dict_id
)

CREATE TABLE Dict_val
(
	dict_val_id int NOT NULL,
	dict_id int NULL,
	dict_val_name varchar(50) NULL,
 CONSTRAINT [PK_Dict_val] PRIMARY KEY CLUSTERED 
(
	dict_val_id
)

CREATE TABLE Country_Dict
(
	dict_id int NOT NULL,
	country_id int NOT NULL,
	dict_val_id int NULL,
 CONSTRAINT PK_Country_Dict PRIMARY KEY CLUSTERED 
(
	dict_id,
	country_id
)

ALTER TABLE Country_Dict ADD CONSTRAINT FK_Country_Dict_Country FOREIGN KEY(country_id)
REFERENCES Country(country_id)
ALTER TABLE Country_Dict CHECK CONSTRAINT FK_Country_Dict_Country

ALTER TABLE Dict_val ADD CONSTRAINT FK_Dict_val_Dict_val FOREIGN KEY(dict_id)
REFERENCES Dictionary(dict_id)
ALTER TABLE Dict_val CHECK CONSTRAINT FK_Dict_val_Dict_val



Это типа как УЖЕ ЕДИНОЖДЫ запрограммировано производителем...

Далее Маша начинает юзать все это дело с клиента:

Код: sql
1.
2.
3.
4.
insert into country
value (1, 'Мексика') 
insert into country
value (2, 'Зимбабве')


Потом она говорит - Петя, ты админ или мать тебя?..
Мне сказали, что ты добавишь континенты, а я их должна привязать к этим долбанным странам!..
Вот служебка...

Петя: да без проблем!

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
Insert into Dictionary
values(1, 'Континент')

Insert into Dict_val
values (1, 1, 'Северная Америка')

Insert into Dict_val
values (1, 2, 'Африка')


Маша говорит - Отлично! И выполняет:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
Insert into Country_Dict
values (1, 1, 1) -- Это Северная Америка для Мексики

Insert into Country_Dict
values (2, 2, 2) -- Это Африка для Зимбабве

Insert into Country_Dict
values (2, 2, 1) -- Это Северная Америка для Зимбабве - не проходит, нарушение ОЦ: либо один континент, либо другой!



Ну типа так же с цементом и валютой...

На каком этапе требуется накат патчей?...
...
Рейтинг: 0 / 0
08.02.2014, 01:25
| Ответить | Цитировать | Написать  
Проектирование атомарных справочников...
    #38554293
Sgt.Pepper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sgt.Pepper
Участник
Извините, ошибся в атрибутах, следует читать так:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
Insert into Country_Dict
values (1, 1, 1) -- Это Северная Америка для Мексики

Insert into Country_Dict
values (2, 1, 2) -- Это Африка для Зимбабве (2 - Зимбабве, 1 - справочник континентов, 2 - значение справочника)

Insert into Country_Dict
values (2, 1, 1) -- Это Северная Америка для Зимбабве - не проходит, нарушение ОЦ: либо один континент, либо другой! Если континент для страны уже присвоен, то второй присвоить нельзя
...
Рейтинг: 0 / 0
08.02.2014, 08:45
| Ответить | Цитировать | Написать  
Проектирование атомарных справочников...
    #38562173
Goffman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Goffman
Участник
Sgt.PepperВ который раз прошу Вас озвучить отступление от классических правил РМД.
Не хотелось бы объяснять очевидные вещи. Раз вы упомянули Кодда, то классический подход можно выразить через правило№0

Sgt.PepperЭдвард Кодд сказал, что связи реализуются только через FK?..
А разве в современных СУБД есть еще какие-нибудь реализации связи? озвучьте если не трудно.

Sgt.PepperЕсли он такого не говорил, то "скорость разработки", "качественное и масштабируемое" решение или финансовые дивиденды участников сделки следует рассматривать в плоскости целесообразности, удобства и т.д., но, возможно, существующие в рамках парадигмы РМД ...
Если решение менее качественно, оно остается менее качественным независимо от финансовых дивидендов участников сделки.
...
Рейтинг: 0 / 0
16.02.2014, 11:27
| Ответить | Цитировать | Написать  
Проектирование атомарных справочников...
    #38562182
Goffman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Goffman
Участник
Sgt.PepperА в Ваших "связях" и "ссылках" есть некие допущения, которые сужают РМД
Не понимаю, почему чем вам так не угодило слово "ссылка". Вам надеюсь знакомо понятие "ссылочная целостность"? Какое слово лежит в основе?


Sgt.Pepper(уж не знаю - по недомыслию или упертости).
Знакомо, все кто рассуждают не так как мы, либо недоумки либо упертые бараны ))

Sgt.PepperУ Вас зацикленность на FK...
Это все равно что сказать строителю: У Вас зацикленность на железобетоне...

GoffmanFK - это вырожденная "связь" (или "ссылка" или как еще ни назовите)...
В общем случае для "связи" или "ссылки" FK является необходимым условием, но недостаточным, если "связь" или "ссылка" реализована классически, через отношения.
Здесь я не очень понял, что вы имеете в виду, если не трудно - поясните, лучше с примером.

Sgt.Pepperточки зрения РМД - совсем не обязательный, а как следствие и п.3...
Ну и что, делать то его все равно надо, я пытаюсь представить проблему вывода справочника в целом.

Sgt.PepperВас не смущает, что даже такие радикалы, как guest_XXXXX, не оспаривают соответствия РМД, а утверждают, что так проектируют только долбо^ебы?...
И я с этим утверждением в общем согласен - у этого подхода есть очень ограниченная область применения, но я возражаю, что:
- он требует "патчей", изменения схемы и внедрения...
- его не следует применять никогда...
Ну раз вы в целом с guest_XXXXX согласны, значит не такой уж он и радикал, как вы говорите.
Что касается изменения схемы, то выходим на второй круг, как вы сможете добавить специфическое поле в отдельно взятом справочнике, не выводя его из "объединенного справочника"? А вывод справочника в отдельную таблицу - это и есть изменение схемы.

Про "его не следует применять никогда..." - в общем то этого никто здесь и не утверждал.
...
Рейтинг: 0 / 0
16.02.2014, 11:58
| Ответить | Цитировать | Написать  
Проектирование атомарных справочников...
    #38562218
sphinx_mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sphinx_mv
Участник
GoffmanSgt.PepperВ который раз прошу Вас озвучить отступление от классических правил РМД.
Не хотелось бы объяснять очевидные вещи. Раз вы упомянули Кодда, то классический подход можно выразить через правило№0 Можно полюбопытствовать, какое нарушение правила, гласящего "реляционная СУБД должна быть способна полностью управлять базой данных, используя связи между данными" допускает подход, в котором данные разных (нескольких) справочников могут храниться в одной таблице?

К дизайну физической модели данных это правило не относится. Точно так же оно не относится даже к логической модели данных (с множеством справочников). Перевод логической модели в схему для физического хранения вполне допускает объединение в одной физической таблице нескольких логических сущностей - в данном конкретном случае отдельных атомарных справочников.

Если запретить возможность хранения атомарных справочников в одной таблице, разделять "условно ФИО" для мужчин и женщин тоже будем в разные (отдельные!) таблицы?! Смысл, кстати, сугубо тот же самый, что и для "атомарного" справочника...

Теперь просто представьте себе кошмар, если пойти по пути Фэйсбука, где, типа, вообще больше 50 "полов" хотят начать использовать, и данные по каждому, типа, "полу" хранятся в разных (и полностью идентичных по структуре) таблицах...
Может, все же стоит согласиться, что использование некоторого дескриминатора (разделителя) вполне справляется с этой задачей? Для "условно ФИО" это признак пола, кстати...

Кстати... :)
Надеюсь, перед постингом этой ссылки Вы прочитали абзац, находящийся непосредственно перед списком правил, которые были предложены в далекой середине 1980-х:
В действительности правила столь строги, что все популярные т. н. "реляционные" СУБД не соответствуют многим критериям.Практически, есть только одна причина, по которой (любое) правило не соблюдается - это правило в реальном мире плохо соответствует связаным с ним ожиданиям...
GoffmanSgt.PepperЕсли он такого не говорил, то "скорость разработки", "качественное и масштабируемое" решение или финансовые дивиденды участников сделки следует рассматривать в плоскости целесообразности, удобства и т.д., но, возможно, существующие в рамках парадигмы РМД ...
Если решение менее качественно, оно остается менее качественным независимо от финансовых дивидендов участников сделки.Вам что больше импонирует - правила, рекомендации или догма?
...
Рейтинг: 0 / 0
16.02.2014, 13:33
| Ответить | Цитировать | Написать  
Проектирование атомарных справочников...
    #38562394
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
GoffmanSgt.PepperЭдвард Кодд сказал, что связи реализуются только через FK?..
А разве в современных СУБД есть еще какие-нибудь реализации связи? озвучьте если не трудно.

)) нелепости... Ключи относятся к ограничениям целостности, а не к связям между типами сущностей... В "современных СУБД" (точнее, СХОД - системах хранения и обработки данных, предназначенных для программистов) связи в принципе не поддерживаются. Они моделируются с помощью элементов структуры (отношений) и ОЦ (ключей).
...
Рейтинг: 0 / 0
16.02.2014, 18:47
| Ответить | Цитировать | Написать  
Проектирование атомарных справочников...
    #38562465
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
Goffman
Если решение менее качественно, оно остается менее качественным независимо от финансовых дивидендов участников сделки.

Угу, т.е. такой параметр как "соотношение цена/качество" Вам не известен.

Да и по поводу темы, на протяжении 10 страниц, нигде не определились критерии "качественно - не качественно" по этому вопросу.
Поскольку Вы утверждаете, что решение менее качественно, то критерии качества в студию.
Только критерии не умозрительные, типа "я так никогда не делаю, поэтому это отстой!", а вполне проверяемые, типа как для автомобилей: Kia = 106 поломки на 100 машин - это качественная машина, а BMW = 114 поломок - остается менее качественной независимо от финансовых дивидендов участников сделки.

По поводу Кодда: где в его 13-ти правилах указано, что нужно заколотить парадное и ходить через чёрный ход для каждого справочника требуется создавать отдельную таблицу?

Скорее против Вашей точки зрения работает правило №9:
Правила .... правило 9: Логическая независимость данных (Logical Data Independence):
Представление данных в приложении не должно зависеть от структуры реляционных таблиц . Если в процессе нормализации одна реляционная таблица разделяется на две, представление должно обеспечить объединение этих данных, чтобы изменение структуры реляционных таблиц не сказывалось на работе приложений.
...
Рейтинг: 0 / 0
16.02.2014, 20:57
| Ответить | Цитировать | Написать  
Проектирование атомарных справочников...
    #38562485
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
zeon11Скорее против Вашей точки зрения работает правило №9:
Правила .... правило 9: Логическая независимость данных (Logical Data Independence):
Представление данных в приложении не должно зависеть от структуры реляционных таблиц . Если в процессе нормализации одна реляционная таблица разделяется на две, представление должно обеспечить объединение этих данных, чтобы изменение структуры реляционных таблиц не сказывалось на работе приложений.

Иначе говоря, модель представления данных не должна зависеть от логической модели данных))) То есть, под вопрос ставится даже вынужденная структура "модель верхнего уровня + маппинг по всем трем аспектам МД + модель нижнего уровня (РМД)". Это одна из ключевых проблем, делающая применение РМД бесполезным практически для всех прикладных задач.
...
Рейтинг: 0 / 0
16.02.2014, 21:59
| Ответить | Цитировать | Написать  
Проектирование атомарных справочников...
    #38562648
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
zeon11Поскольку Вы утверждаете, что решение менее качественно, то критерии качества в студию.

Ну, возможно, имелось виду большее соответствие структуры БД предметной области. Возможно, это упростит восприятие схемы, декларативные ОЦ и какие-то запросы.

zeon11
По поводу Кодда: где в его 13-ти правилах указано, что нужно заколотить парадное и ходить через чёрный ход для каждого справочника требуется создавать отдельную таблицу?

Скорее всего, эти правила - все же требования к РСУБД, а не РМД. И потому как бы там про то, чтобы СУБД претендующие на Р, позволяли использовать все достоинства РМД, т.е. не компрометировали ее.

В частности,

zeon11Скорее против Вашей точки зрения работает правило №9:

работает против точек зрения, производителей РСУБД, допускающих отсутствие представлений в их продукте, но возможности присутствия буквы “Р”.

Есть у нас приложение и БД. Мы решили сменить имя поля, сделать в реляционной схеме декомпозицию таблиц. Если приложение видит представления, а схему, то код приложений трогать не придется, только изменить приложения.

В частности, это преимущество РМД, над ООМД, в которых типа нет представлений. А никак ни разных конкретных РМД, так обе могут юзать это достоинство, если только разработчик РСУБД это обеспечил.
...
Рейтинг: 0 / 0
17.02.2014, 08:58
| Ответить | Цитировать | Написать  
Проектирование атомарных справочников...
    #38563193
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
опечатка:
"Если приложение видит представления, а схему, то код приложений трогать не придется, только изменить приложения.
"
следует читать:

"Если приложение видит представления, а не таблицы, то код приложений трогать не придется, только изменить представления.
"
...
Рейтинг: 0 / 0
17.02.2014, 15:40
| Ответить | Цитировать | Написать  
Проектирование атомарных справочников...
    #38563705
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
vadiminfoЕсли приложение видит представления, а не таблицы, то код приложений трогать не придется, только изменить представления.
1) Приложение "видит" совсем другую структуру, имеет дело с другими ОЦ и написано на другом языке. Поскольку не легко разработать и повторно применять архитектуру "модель верхнего уровня + маппинг по всем трем аспектам МД + модель нижнего уровня (РМД)" то - перманентное программирование. И это (обеспечение программистов работой на всю жизнь) вполне можно отнести к достоинствам реляционной технологии.
2) Код, например, умножающий A на B, конечно не придется трогать после, например, удаления B из таблицы и из представления, если "разработчик РСУБД это обеспечил".
...
Рейтинг: 0 / 0
17.02.2014, 22:08
| Ответить | Цитировать | Написать  
Проектирование атомарных справочников...
    #38563719
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
Бредятина... не легко разработать и повторно применять архитектуру "модель верхнего уровня + маппинг по всем трем аспектам МД + модель нижнего уровня (РМД)" ...
Надо думать, что ЧАЛОвскую ахинею "не легко разработать" и тем более "повторно применять". К счастью, в этом нет нужды: эпоха РМД а дворе. В МУМПСы и устаревшие идеи 60-х в прошлом.
...
Рейтинг: 0 / 0
17.02.2014, 22:38
| Ответить | Цитировать | Написать  
Проектирование атомарных справочников...
    #38563730
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
vadiminfoБредятина... не легко разработать и повторно применять архитектуру "модель верхнего уровня + маппинг по всем трем аспектам МД + модель нижнего уровня (РМД)" ...
Надо думать, что ЧАЛОвскую ахинею "не легко разработать" и тем более "повторно применять". К счастью, в этом нет нужды: эпоха РМД а дворе. В МУМПСы и устаревшие идеи 60-х в прошлом.
))) Уточню:
1) Приложение "видит" совсем другую структуру, имеет дело с другими ОЦ и написано на другом языке. Поскольку не легко разработать и повторно применять архитектуру "модель верхнего уровня + маппинг по всем трем аспектам МД + модель нижнего уровня (РМД)" то - перманентное программирование. И это (обеспечение программистов работой на всю жизнь) вполне можно отнести к достоинствам реляционной технологии.
2) Код, например, умножающий A на B, конечно не придется трогать после, например, удаления B из таблицы и из представления, если "разработчик РСУБД это обеспечил".

Вы допускаете серьезные ошибки, когда пишете что-то про БД) И когда я Вам на них указываю, обижаетесь, и начинаете писать не по существу) Нечего сказать по существу, так не пишите здесь сообщения... Разумеется эпоха РМД на дворе, и я это ясно подтвердил)))
...
Рейтинг: 0 / 0
17.02.2014, 23:02
| Ответить | Цитировать | Написать  
Проектирование атомарных справочников...
    #38563749
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
Бредятина Разумеется эпоха РМД на дворе, и я это ясно подтвердил
Наконец-то до Вас дошло это через 30 лет.
МУМПС здесь подбрасывали вместо РМД. Мешочки, Дореляционную ОМД, объектный нафигатор. Смешно просто вспоминать. Теперь, надеюсь, взялись за ум.
...
Рейтинг: 0 / 0
17.02.2014, 23:36
| Ответить | Цитировать | Написать  
25 сообщений из 325, страница 10 из 13
  10  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование атомарных справочников...
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=38563749&tid=1540946]:
 0ms
get settings:
 12ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 133ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 53ms
get tp. blocked users:
 1ms
others: 235ms
total:  465ms
созд. / загр.: 465ms
x
x
Закрыть


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