Хранение данных с гибкой структурой и запросы к ним / Сравнение СУБД

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Хранение данных с гибкой структурой и запросы к ним

25 сообщений из 257, страница 9 из 11

все

Хранение данных с гибкой структурой и запросы к ним

#38291263

PSV100

Гость

U-geneЗабудьте про EAV (чур меня). Ваша накладная в лоб отобразится в две таблицы. Думаю, что в реальной практике такое дублирование (прям один-в-один, как Вы изобразили) тоже может использоваться с теми же целями.

Уже хорошо, что внизу появились интуитивно-адекватные таблицы.

Но, всё таки, вынужден обратить внимание. Пусть "накладная" задана в виде "прикладной модели пользователя":

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

Накладная:
  	Номер      => STRING
	Дата  	   => DATETIME
	Поставщик  => INTEGER
	...
	Содержимое:
		Товар  => INTEGER
		Цена   => CURRENCY
		Сумма  => CURRENCY
		...

В каком-нибудь ООП-языке для программы эту модель могут определить как-то так:

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

struct Накладная
{ 	Номер:      STRING;
	Дата:  	    DATETIME;
	Поставщик:  INTEGER;
	...
	struct Содержимое
	{ 	
		Товар:   INTEGER;
		Цена:    CURRENCY;
		Сумма:   CURRENCY;
		...
	}
};

Внутри RxO вынуждены будут задать так:

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.

CREATE CLASS Накладная
( 	Номер      STRING,
	Дата  	   DATETIME,
	Поставщик  INTEGER,
	...
	Содержимое SET OF
	( 	
		Товар:   INTEGER,
		Цена:    CURRENCY,
		Сумма:   CURRENCY,

		-- а эти данные вынужденны дублировать:
		Дата  	   DATETIME,
		Поставщик  INTEGER,
		...
	)
);

Иными словами, в RxO классы выражают прикладные сущности и, получается, одновременно и физическую организацию данных. О возможных последствиях был смежный пост.

...

Рейтинг:

0 / 0

08.06.2013, 14:06

| Ответить | Цитировать | Написать

Хранение данных с гибкой структурой и запросы к ним

#38291280

PSV100

Гость

U-geneОк. А дальше все гораздо проще. Где-нибудь делаем

ALTER Документы REALIZE (Номер, Дата, ...) AS STORED.

Всё. Реализации компонентов и методов тоже наследуются, пока не переопределим. Значит и в объектах классов "Акты" и "Документы" эти компоненты тоже будут хранимыми. Ни о чем больше думать не надо. Нет никаких "отдельных хранилищ для классов", про которые отдельно думать надо. Нет никакой отдельной "физической модели" :).

Странно, если есть какое-то "STORED", значит же есть и какое-то хоронилище. Ну да ладно. То, что не нужно ни о чём думать - мне нравится, никаких хранилищ, никакой "физики" и т.д. - это же мечта.

Попробую построить проект согласно такой идеологии RxO. Напомню, требуется реализовать обработку двух элементарных документов, представим их в "модели пользователя":

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

Накладная на отгрузку:
  	Номер      => STRING
	Дата  	   => DATETIME
	Поставщик  => INTEGER
	...


Приходный акт:
  	Номер      => STRING
	Дата  	   => DATETIME
	Поставщик  => INTEGER
	...

"Приходный акт" - это некие виртуальные документы, они могут отражать те же накладные, поступившие на "склад" из "производства", закупку на стороне, акты инвентаризации и т.д. (когда нужно, они трансформируются в реальные физические документы). Поэтому акты не вводят непосредственно на складе, в данном случае, как только в "производстве" выписали накладную, то сразу же на складе автоматом должен появится "акт".

Итак, приступим. Согласно методике RxO нам достаточно выразить прикладные сущности:

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.

CREATE CLASS Документы
(   
    Номер      STRING,
    Дата       DATETIME,
    Поставщик  INTEGER,
    ...
);

CREATE CLASS Накладные EXTEND Документы
(
);

CREATE CLASS Акты EXTEND Документы
(
);

-- и задействуем ключевой "STORED":
ALTER Документы REALIZE (Номер, Дата, ...) AS STORED.

Теперь на "производстве" создают накладную:

NEW Накладные WITH SET
.Номер := "A-01"
.Дата := to_date("08.06.2013")
.Поставщик := 15;
...

Теперь на складе сделают выборку из "Актов" (т.е. не из "накладных" или "документов", а именно из "актов" как своя прикладная сущность):

SELECT .Номер, .Дата, .Поставщик, ... FROM Акты

Ура! Акт появился!

Далее, в системе появляются "Акты инвентаризации", теперь и их нужно впихнуть. Тут выясняется, что вместо "Поставщика" нужно "Подразделение" (мол начальство указало, что так корректнее). Ну что же, у нас ведь именно прикладная модель (совмещённая с "физикой"), будет опять ООП-рефакторить, обычное дело, нам уже давно не привыкать, да и умная IDE нам поможет:

Код: 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.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.

-- теперь общие документы такие:
CREATE CLASS Заготовка_для_документов
(   
    Номер      STRING,
    Дата       DATETIME,
    ...
);

-- ещё одна заготовка
CREATE CLASS Внешние_документы EXTEND Заготовка_для_документов
(   
    Поставщик  INTEGER,
    ...
);

-- и ещё
CREATE CLASS Внутренние_документы EXTEND Заготовка_для_документов
(   
    Подразделение  INTEGER,
    ...
);

-- накладные теперь такие
CREATE CLASS Накладные EXTEND Внешние_документы
(
	...
);


-- новые акты инвентаризации
CREATE CLASS Акты_инвентаризации EXTEND Внутренние_документы
(
	...
);


-- теперь у нас есть "Приходные акты", возникающие
-- из "накладных" и "актов инвентаризации".
--
-- Ключевой момент: теперь фиг поймёшь, от какого предка наследоваться,
-- я уже для простоты взял "Внешние_документы", с расчётом "совместимости"
-- разных типов документов, которые составляют сущность этих "Приходные актов".
-- А так, вынуждены организовать иерархию, указанную выше, ещё муторнее.
--
-- Также вынужденны иметь свойство "Источник",
-- которое указывает или на "Поставщика" или на "Подразделение",
-- что требует отдельной его реализации как "вычислимое",
-- для простоты этот момент опускаем (я толком и не понимаю как)
CREATE CLASS Приходные_акты EXTEND Внешние_документы
(
    Источник  INTEGER,
    ...
);

-- и не забываем за ключевой "STORED", которых теперь также больше,
-- как и всего остального, причём, фактически из-за капризов
-- в "прикладной" модели:

ALTER Заготовка_для_документов REALIZE (Номер, Дата, ...) AS STORED;

ALTER Внешние_документы REALIZE (Поставщик, ...) AS STORED;

ALTER Внутренние_документы REALIZE (Подразделение, ...) AS STORED;

Наконец-то наваяли, и удовлетворили начальство.

Теперь в "производстве":

NEW Накладные WITH SET
.Номер := "A-01"
.Дата := to_date("08.06.2013")
.Поставщик := 15;
...

Где-то сделали акт инвентаризации:

NEW Акты_инвентаризации WITH SET
.Номер := "И-01"
.Дата := to_date("08.06.2013")
.Подразделение := 234;
...

Теперь на складе делают выборку документов:

SELECT .Номер, .Дата, .Источник, ... FROM Приходные_акты

Опять ура! Все документы на месте. Работу сдали.

Я правильно всё спроектировал? (согласно идеологии RxO: "ни о чем больше думать не надо. Нет никаких "отдельных хранилищ для классов", про которые отдельно думать надо. Нет никакой отдельной "физической модели")

Документы на складе будут появляться? (лично я уверен что нет. И я так и не смог решить эту задачу, с учётом того, чтобы не было нигде никакого дублирования данных, всё везде оптимально, красивенько, и прикладная модель причёсана)

...

Рейтинг:

0 / 0

08.06.2013, 14:32

| Ответить | Цитировать | Написать

Хранение данных с гибкой структурой и запросы к ним

#38291354

U-gene

Участник

Откуда: Москва. Россия

Сообщения: 1 532

Рейтинг: 0 / 0

PSV100U-geneОк. А дальше все гораздо проще. Где-нибудь делаем

ALTER Документы REALIZE (Номер, Дата, ...) AS STORED.

Всё. Реализации компонентов и методов тоже наследуются, пока не переопределим. Значит и в объектах классов "Акты" и "Документы" эти компоненты тоже будут хранимыми. Ни о чем больше думать не надо. Нет никаких "отдельных хранилищ для классов", про которые отдельно думать надо. Нет никакой отдельной "физической модели" :).

Странно, если есть какое-то "STORED", значит же есть и какое-то хоронилище. Ну да ладно. То, что не нужно ни о чём думать - мне нравится, никаких хранилищ, никакой "физики" и т.д. - это же мечта.

Попробую построить проект согласно такой идеологии RxO. Напомню, требуется реализовать обработку двух элементарных документов, представим их в "модели пользователя":

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

Накладная на отгрузку:
  	Номер      => STRING
	Дата  	   => DATETIME
	Поставщик  => INTEGER
	...


Приходный акт:
  	Номер      => STRING
	Дата  	   => DATETIME
	Поставщик  => INTEGER
	...

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.

CREATE CLASS Документы
(   
    Номер      STRING,
    Дата       DATETIME,
    Поставщик  INTEGER,
    ...
);

CREATE CLASS Накладные EXTEND Документы
(
);

CREATE CLASS Акты EXTEND Документы
(
);

-- и задействуем ключевой "STORED":
ALTER Документы REALIZE (Номер, Дата, ...) AS STORED.

Теперь на "производстве" создают накладную:

NEW Накладные WITH SET
.Номер := "A-01"
.Дата := to_date("08.06.2013")
.Поставщик := 15;
...

Теперь на складе сделают выборку из "Актов" (т.е. не из "накладных" или "документов", а именно из "актов" как своя прикладная сущность):

SELECT .Номер, .Дата, .Поставщик, ... FROM Акты

Ура! Акт появился!

Нет, так ракеты не летают.

Классы Акты и Накладные - разные подклассы (непересекающиеся подмножества) общего суперкласса Документы. Новая Накладная будет видна как объект класса Документы, но в множестве Акты она не появится. Сели мы создадим просто Документ, он из подклассов виден не будет.

Если я что то понимаю, накладная и акт - два разных документа (один может быть основанием для второго). Соответственно, и в системе они должны быть разными объектами.

Дальше, мне показалось, то же самое.

...

Рейтинг:

0 / 0

08.06.2013, 18:10

| Ответить | Цитировать | Написать

Хранение данных с гибкой структурой и запросы к ним

#38291592

Бредятина

Участник

Откуда: Москва

Сообщения: 4 039

Рейтинг: 0 / 0

PSV100Здесь тогда нужно говорить о концептуальных ошибках именно конкретной реализации или типовых технологий, а не в целом, что ORM - это ошибка природы.
ORM (где под О понимается семантический аспект, в первую очередь) - объективная необходимость. Так как прямое использование РМД невозможно. Это не значит, вероятно, что РМД - ошибка природы. Собственно, U-gene и доказывает, что РМД - не ошибка, обходясь, как он уверяет, без ORM.

...

Рейтинг:

0 / 0

09.06.2013, 10:03

| Ответить | Цитировать | Написать

Хранение данных с гибкой структурой и запросы к ним

#38291594

Бредятина

Участник

Откуда: Москва

Сообщения: 4 039

Рейтинг: 0 / 0

vadiminfoPSV100 тип моделей может быть один и тот же. .
Это означает, что может быть и разным.

Т.е. в любом случае мыстль "модель данных должна быть одна и та же на концептуальном и логическом уровнях", скорее всего, связана с какой-то идеей впарить что РБД не БД, или тому подобной ахинеей.
Поскольку де мол БД не дложна, а РБД так поступает.
Мы же уже договорились, что я - идиот и впариваю ахинею))
Однако, то, что семантически развитая логическая МД может использоваться, как концептуальная - это просто факт, к сожалению. То есть, идиоты, иногда,оказываются правы))

...

Рейтинг:

0 / 0

09.06.2013, 10:06

| Ответить | Цитировать | Написать

Хранение данных с гибкой структурой и запросы к ним

#38291598

Бредятина

Участник

Откуда: Москва

Сообщения: 4 039

Рейтинг: 0 / 0

PSV100Давая ссылку на цитату от коллеги Бредятина где-то выше в своём исходном посте, я лишь подразумевал только одно предложение из всего контекста, которое я вспомнил тогда, уже ночью строчив свой текст. Это следующий тезис: "модель данных должна быть одна и та же на концептуальном и логическом уровнях". Затем Вы сделали уточнение на счёт не одной модели, а об одном типе моделей. В результате в моём сознании эта фраза трансформировалась (а изначально я так и подразумевал) в понятие того, что для разных уровней (логического, выражающего прикладную область, и физического, отражающего реальное устройство данных) желательно иметь модели схожего или близкого типа, чтобы было меньше проблем со всякой трансформацией и прочими перегонялками данных по всем фронтам.
Вы напрасно добавили физический уровень. Ведь речь шла только о проектировании (на основе МД в первом смысле, по дейту) и использовании МД во втором смысле, по Дейту (независимо от физической реализации данных). При использовании "реляционных систем" архитектура "модель верхнего уровня+маппинг+РМД" неизбежна. Если только не заменить РМД на модель EAV или использовать разработку U-gene))

...

Рейтинг:

0 / 0

09.06.2013, 10:13

| Ответить | Цитировать | Написать

Хранение данных с гибкой структурой и запросы к ним

#38291602

Бредятина

Участник

Откуда: Москва

Сообщения: 4 039

Рейтинг: 0 / 0

U-geneЯ везде использую хорошо известный термин "трансляция" и считаю, что люди меня понимают(как правило, так оно и есть).Но, оказывается, некоторые настолько погрязли в маппинге, что ничего другого не видят. Например Бредятина. И здесь, и в других местах я неоднократно объяснял ему, что речь идет о трансляции ОО-команд, а он считает, что всего лишь игра слов, и, поэтому, тут же начинал говорить про "МД верхнего уровня+маппинг+РМД".
Заблуждение. Причем, как мне кажется, умышленное)) Никто здесь Вас не поддерживает, как я. И эта поддержка заключается в том, чтобы детально разобраться, и показать, что маппинга (так же хорошо известный термин) по всем трем аспектам (структура+ОЦ+манипулирование) в Вашей системе нет в принципе. Поэтому, не стоит философствовать говорите по существу, используя удобные для Вас термины.
U-geneКстати, всегда думал, что ... разница между программистами и спецами по БД высосана из пальца. Оказывается, я ошибался.
Это точно. Между ними непреодолимая пропасть))

...

Рейтинг:

0 / 0

09.06.2013, 10:20

| Ответить | Цитировать | Написать

Хранение данных с гибкой структурой и запросы к ним

#38291605

Бредятина

Участник

Откуда: Москва

Сообщения: 4 039

Рейтинг: 0 / 0

Итак, мы рассматриваем простые примеры. Причем, вместо очевидной (пока) для системы U-gene гипотезы "Мир состоит (только) из сущностей, обладающих свойствами", и понятия Тип сущности, мы договорились (пока) не рассматривать никакие гипотезы об окружающем мире (и моделируемых предметных областях, в частности), и заменили Тип сущности на Класс:

П1
Классы:
Студент {Фамилия, Имя, (Изучает, Предмет)}
Предмет {Наименование}

П2
Классы:
Документ {Дата, Организация-получатель, (Имеет, Отгрузка {(Относится к, Товар), Количество, Сумма}}
Товар {Наименование}

Но, Классы существуют только при описании предметной области (и, извините, на уровне хранения данных). Любой запрос возвращает отношение РМД, но не класс . Например, запрос, эквивалентный
SELECT * FROM Студент
вернет (считаем, что системные идентификаторы всегда есть в результате запроса):

1 Иванов Петр 1 Алгебра
1 Иванов Петр 7 География
2 Петров Иван 1 Алгебра
2 Петров Иван 3 Химия

U-gene, пожалуйста, поправьте, если что не так.[/quot]

...

Рейтинг:

0 / 0

09.06.2013, 10:30

| Ответить | Цитировать | Написать

Хранение данных с гибкой структурой и запросы к ним

#38291661

U-gene

Участник

Откуда: Москва. Россия

Сообщения: 1 532

Рейтинг: 0 / 0

Бредятина,

Нет, пока с терминами не разберемся, дальше разговаривать смысла нет.

Итак "маппинг" подразумевает обмен данными между двумя системами данных и выполняет необходимое для обмена преобразование структур этих данных.
Уточняю. Первая система данных - это линейная память, используемая программой написанной на ОО языке. Вторая система данных - реляционная БД.

Трансляция подразумевает преобразование команд , управляющих одной единственной системой данных.

В этом смысле, действия, выполняемые RxO аналогичны действиям, которые выполняет OO компилятор в момент создания ОО программы. Конечно, RxO учитывает специфику исполняющей машины, что проявляется, например, в тех же типах атрибутов объекта, которые есть "значения типов, допускающих реляционное присваивание", и в очень многих других местах, в т.ч. в том факте, что мы уходим от программы к декларативным командам. Никому в голову не придет сказать, что существует какие-то "концептуальные ошибки" или "несостыковки" между транслятором и целевой машиной.

Если Вы согласны с такой трактовкой этих двух терминов, то можно будет продолжить.

...

Рейтинг:

0 / 0

09.06.2013, 13:21

| Ответить | Цитировать | Написать

Хранение данных с гибкой структурой и запросы к ним

#38291703

Бредятина

Участник

Откуда: Москва

Сообщения: 4 039

Рейтинг: 0 / 0

U-geneНет, пока с терминами не разберемся, дальше разговаривать смысла нет.
Разумеется! Это же очевидно.
U-geneИтак "маппинг" подразумевает обмен данными между двумя системами данных и выполняет необходимое для обмена преобразование структур этих данных.
Уточняю. Первая система данных - это линейная память, используемая программой написанной на ОО языке. Вторая система данных - реляционная БД.
Отлично. Уточните: данные хранятся в реляционной БД в каком виде? В реляционном? Атрибуты отношений - это свойства "неизвестно чего" (так как Вы запрещаете использовать, например, такие термины как "сущность" или связь")? Или еще и термин "свойство" мы тоже не можем использовать?
U-geneТрансляция подразумевает преобразование команд , управляющих одной единственной системой данных.
В этом смысле, действия, выполняемые RxO аналогичны действиям, которые выполняет OO компилятор в момент создания ОО программы. Конечно, RxO учитывает специфику исполняющей машины, что проявляется, например, в тех же типах атрибутов объекта, которые есть "значения типов, допускающих реляционное присваивание", и в очень многих других местах, в т.ч. в том факте, что мы уходим от программы к декларативным командам. Никому в голову не придет сказать, что существует какие-то "концептуальные ошибки" или "несостыковки" между транслятором и целевой машиной.
Если Вы согласны с такой трактовкой этих двух терминов, то можно будет продолжить.
Конечно! Согласен! Я уже продолжил - см. вопрос выше.

...

Рейтинг:

0 / 0

09.06.2013, 14:48

| Ответить | Цитировать | Написать

Хранение данных с гибкой структурой и запросы к ним

#38291783

vadiminfo

Участник

Откуда: Обнинск

Сообщения: 4 779

Рейтинг: 0 / 0

Бредятина... я - ... впариваю ахинею))

Еще бы.

БредятинаОднако, то, что семантически развитая логическая МД может использоваться, как концептуальная - это просто факт, к сожалению.
Если эта " семантически развитая логическая МД " хуже на логическом уровне РМД (а это так пока длится реляционная эпоха), а тем более и ER , судя по всему, лучшая на концептуальном, то хоть "семантически развитая" и может, но кому это надо.
Таких семантически развитых предлагалось в свое время. Так и остались чисто академическими.
Т.е. не должна БД использовать такую "семантически развитая логическая МД", если она хуже на логическом уровне РМД, скорее всего.
"Я могу есть только лучший обед. Я не могу есть гадкого обеда" (С) Гоголь "Хлестаков"

...

Рейтинг:

0 / 0

09.06.2013, 18:43

| Ответить | Цитировать | Написать

Хранение данных с гибкой структурой и запросы к ним

#38291937

Бредятина

Участник

Откуда: Москва

Сообщения: 4 039

Рейтинг: 0 / 0

vadiminfoЕще бы.
Что РМД - ошибка природы? Быстро согласились, на этот раз))
vadiminfoЕсли эта " семантически развитая логическая МД " хуже на логическом уровне РМД (а это так пока длится реляционная эпоха),
Факт, что это не так. На логическом уровне РМД уступает по всем аспектам. А эпоха длится, именно потому что впаривают, используя крайне низкий уровень образования))
vadiminfoа тем более и ER , судя по всему, лучшая на концептуальном, то хоть "семантически развитая" и может, но кому это надо.
Тем, кто впаривает РМД, конечно, не надо)) А те, кому впаривают, просто ни о чем не знают.
vadiminfoТаких семантически развитых предлагалось в свое время. Так и остались чисто академическими.
Говорите конкретно, какие МД верхнего уровня Вы хотите добавить к М0-М5. Что там предлагалось, и в какое время))
vadiminfoТ.е. не должна БД использовать такую "семантически развитая логическая МД", если она хуже на логическом уровне РМД, скорее всего.
Не скорее всего, а абсолютно точно.
vadiminfo"Я могу есть только лучший обед. Я не могу есть гадкого обеда" (С) Гоголь "Хлестаков"
Который врал, периодически. Впаривал РМД, своего рода, так сказать))

...

Рейтинг:

0 / 0

10.06.2013, 00:28

| Ответить | Цитировать | Написать

Хранение данных с гибкой структурой и запросы к ним

#38292023

mad_nazgul

Участник

Сообщения: 3 848

Рейтинг: 0 / 0

БредятинаФакт, что это не так. На логическом уровне РМД уступает по всем аспектам. А эпоха длится, именно потому что впаривают, используя крайне низкий уровень образования))

Ее не "впаривают", просто альтернатив нет, в принципе.
Для РМД есть конкретная реализация - SQL.
Которая (реализация) с одной стороны проста, с другой достаточно мощная и гибкая, что покрывает почти весь класс задач.

<:o)

...

Рейтинг:

0 / 0

10.06.2013, 07:43

| Ответить | Цитировать | Написать

Хранение данных с гибкой структурой и запросы к ним

#38292033

vadiminfo

Участник

Откуда: Обнинск

Сообщения: 4 779

Рейтинг: 0 / 0

Бредятина Быстро согласились, на этот раз))

Почему на это раз? Давно согласен с этим:

Бредятина Мы же уже договорились, что я - идиот и впариваю ахинею))

БредятинаФакт, что это не так.
На логическом уровне РМД уступает по всем аспектам.
Угу. Только тем кто 30 лет назад ошибся выбрав не РМД, теперь рассуждать про аспекты. Смешно.

БредятинаА эпоха длится, именно потому что впаривают, используя крайне низкий уровень образования))

Да. Да. Ну где им до Вашего образования? Даже ошибок у Дейта им не удается найти.

Так или иначе:
Бредятина"модель данных должна быть одна и та же на концептуальном и логическом уровнях" -

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

РМД может быть по производительности могут где-то потеснить. Но по логике пока что не видно ничего.

...

Рейтинг:

0 / 0

10.06.2013, 08:30

| Ответить | Цитировать | Написать

Хранение данных с гибкой структурой и запросы к ним

#38292043

Бредятина

Участник

Откуда: Москва

Сообщения: 4 039

Рейтинг: 0 / 0

mad_nazgulЕе не "впаривают", просто альтернатив нет, в принципе.
И чтобы впаривать вот так и учат в университетах. Вот, видите, и Вас так научили))
mad_nazgulДля РМД есть конкретная реализация - SQL.
Бесполезная реализация.
14026636
За 30 лет нашел лишь одно ясное применение алгебре, когда она органично сочетается с семантикой.
mad_nazgulКоторая (реализация) с одной стороны проста, с другой достаточно мощная и гибкая, что покрывает почти весь класс задач.
Заблуждение. Практически, ни одной задачи)) Поэтому и приходится применять архитектуру "модель+маппинг+РМД", часто даже не РМД, а EAV.

...

Рейтинг:

0 / 0

10.06.2013, 08:44

| Ответить | Цитировать | Написать

Хранение данных с гибкой структурой и запросы к ним

#38292048

Бредятина

Участник

Откуда: Москва

Сообщения: 4 039

Рейтинг: 0 / 0

vadiminfoПочему на это раз? Давно согласен с этим
Что РМД - ошибка природы? Это новость для меня))
vadiminfoУгу. Только тем кто 30 лет назад ошибся выбрав не РМД, теперь рассуждать про аспекты. Смешно.
Опять ошибка. Я выбрал именно РМД. Поэтому и знаю ее лучше, чем кто-либо другой. Убедился в непреодолимости недостатков, связанных с невозможностью реализовать основные принципы БД.
vadiminfoДа. Да. Ну где им до Вашего образования?
Не "им", а "вам".
vadiminfoДаже ошибок у Дейта им не удается найти.
А их не нужно искать. Они лежат на поверхности. "Они" их просто умалчивают, чтобы впаривать))
vadiminfoНеуклюжая попытка абсолютизировать мелкий недотаток (если это вообще недостаток). Так как с любым образованием ясно, что лучшее из лучшего на на любом уровне выбрать лучший для этих уровней тип МД, если он даже ни для каких других уровней или чего либо вообще другого не подходит.
То, что модель данных должна быть одна и та же на концептуальном и логическом уровнях - это просто очевидно)) Не нужны никакие попытки, чтобы что-то абсолютизировать. Вернитесь к теме. наконец-то. И спросите U-gene. У него - разные модели что ли???))) [Внимание. Ловушка]
vadiminfoРМД может быть по производительности могут где-то потеснить. Но по логике пока что не видно ничего.
Конечно, конечно. Так ведь научили))

...

Рейтинг:

0 / 0

10.06.2013, 08:56

| Ответить | Цитировать | Написать

Хранение данных с гибкой структурой и запросы к ним

#38292101

vadiminfo

Участник

Откуда: Обнинск

Сообщения: 4 779

Рейтинг: 0 / 0

Любой может убедиться, что там было не про мечту всей жизни ЧАЛа:

БредятинаЧто РМД - ошибка природы?

А про реальное какие-то положение вещей:

БредятинаМы же уже договорились, что я - идиот и впариваю ахинею))

А других в неправде упрекает. Хорош правдист. Нечего сказать.

БредятинаПоэтому и знаю ее лучше, чем кто-либо другой.
Оно и видно. "Знание" так и прет.

БредятинаТо, что модель данных должна быть одна и та же на концептуальном и логическом уровнях - это просто очевидно))

Ну, разве, для тех для кого между уровнями разницы нет. "Должна быть" одна и таже модель повидмому, потому уровни ничем не "должны" отличаьтся. Иначе как бы и модели могут отличаться, скорее всего.

БредятинаКонечно, конечно. Так ведь научили))

Да уж спасибо, что не как ЧАЛа научили.

...

Рейтинг:

0 / 0

10.06.2013, 09:46

| Ответить | Цитировать | Написать

Хранение данных с гибкой структурой и запросы к ним

#38292183

Yo.!

Гость

Бредятина Бесполезная реализация.
14026636

полезная. и вы это увидите когда поработаете более года. алгоритмы обработки OLTP транзакций меняются с годами и ростом данных. данные в OLTP растут экспоненциально, системы типа MUPS, не способные подгонять алгоритмы обработки данных на лету ушли на свалку истории безвозвратно.
имхо после разочарования ИТ индустрии в ОО подходах, РМД будет искать варианты замены процедурных расширений на какую-то декларативную хрень.

...

Рейтинг:

0 / 0

10.06.2013, 10:49

| Ответить | Цитировать | Написать

Хранение данных с гибкой структурой и запросы к ним

#38292304

Бредятина

Участник

Откуда: Москва

Сообщения: 4 039

Рейтинг: 0 / 0

Yo.!полезная. и вы это увидите когда поработаете более года. алгоритмы обработки OLTP транзакций меняются с годами и ростом данных. данные в OLTP растут экспоненциально, системы типа MUPS, не способные подгонять алгоритмы обработки данных на лету ушли на свалку истории безвозвратно.
Наивно)) Мягко говоря. Поработал с БД более 30 лет. MUMPS, к моему великому сожалению, остается единственной пригодной средой создания и эксплуатации БД, в том числе, именно потому что легкость "подгонки алгоритмов" превосходит "реляционные системы" настолько, что даже сравнивать не имеет смысла.
Yo.!имхо после разочарования ИТ индустрии в ОО подходах, РМД будет искать варианты замены процедурных расширений на какую-то декларативную хрень.
Я детально пояснял про то, что подходы, основанные на ООП, просто не имеют к БД никакого отношения. Разумеется, разочарование))

...

Рейтинг:

0 / 0

10.06.2013, 12:12

| Ответить | Цитировать | Написать

Хранение данных с гибкой структурой и запросы к ним

#38292319

Бредятина

Участник

Откуда: Москва

Сообщения: 4 039

Рейтинг: 0 / 0

vadiminfoЛюбой может убедиться,
Что РМД - ошибка природы? Разумеется. Это я честно копирую Ваш стиль обсуждения вопросов по существу, вероятно, общепринятый на sql.ru. Видите, стараюсь, учусь))
Мы же уже договорились, что я - идиот и впариваю ахинею)) Вот, пытаюсь понять Ваше мнение о системе U-gene.
vadiminfoОно и видно. "Знание" так и прет.
Вроде U-gene про БЗ не говорил. Из какой части системы оно прет?
vadiminfoНу, разве, для тех для кого между уровнями разницы нет. "Должна быть" одна и таже модель повидмому, потому уровни ничем не "должны" отличаьтся. Иначе как бы и модели могут отличаться, скорее всего.
То, что модель данных должна быть одна и та же на концептуальном и логическом уровнях - это просто очевидно)) Для всех.
vadiminfoДа уж спасибо, что не как ЧАЛа научили.
Вернитесь к теме. наконец-то. И спросите U-gene. У него - разные модели что ли???))) [Внимание. Ловушка]
Предположим, что Вы это не сознательно пропустили, а по невнимательности))

...

Рейтинг:

0 / 0

10.06.2013, 12:20

| Ответить | Цитировать | Написать

Хранение данных с гибкой структурой и запросы к ним

#38292351

Yo.!

Гость

БредятинаНаивно)) Мягко говоря. Поработал с БД более 30 лет. MUMPS, к моему великому сожалению, остается единственной пригодной средой создания и эксплуатации БД, в том числе, именно потому что легкость "подгонки алгоритмов" превосходит "реляционные системы" настолько, что даже сравнивать не имеет смысла.

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

БредятинаЯ детально пояснял про то, что подходы, основанные на ООП, просто не имеют к БД никакого отношения. Разумеется, разочарование))
не имеют. а кто-то с этим спорит ?

...

Рейтинг:

0 / 0

10.06.2013, 12:33

| Ответить | Цитировать | Написать

Хранение данных с гибкой структурой и запросы к ним

#38292395

vadiminfo

Участник

Откуда: Обнинск

Сообщения: 4 779

Рейтинг: 0 / 0

БредятинаЧто РМД - ошибка природы?
Это Вашу мечту Вы пытались подбросить вместо единственной удачной Вашей мыстли:

БредятинаМы же уже договорились, что я - идиот и впариваю ахинею))

БредятинаТо, что модель данных должна быть одна и та же на концептуальном и логическом уровнях - это просто очевидно)) Для всех.

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

БредятинаУ него - разные модели что ли???)))
У большинчства пока разные: ER и РМД..

...

Рейтинг:

0 / 0

10.06.2013, 12:56

| Ответить | Цитировать | Написать

Хранение данных с гибкой структурой и запросы к ним

#38292486

Бредятина

Участник

Откуда: Москва

Сообщения: 4 039

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

10.06.2013, 13:48

| Ответить | Цитировать | Написать

Хранение данных с гибкой структурой и запросы к ним

#38292503

Бредятина

Участник

Откуда: Москва

Сообщения: 4 039

Рейтинг: 0 / 0

vadiminfoЭто Вашу мечту Вы пытались подбросить вместо единственной удачной Вашей мыстли
Рад, что поняли, наконец-то, что РМД - ошибка природы))
vadiminfoОчевидно, что это попытка сомнителный недосток (возможно, это и не недостаток вообще) превратить в неприемлемый. И впарить ахинею типа РБД якобы плохая БД. Типа "знания" которые так и прут.
То, что модель данных должна быть одна и та же на концептуальном и логическом уровнях - это просто очевидно)) Для всех.
У U-gene не БЗ. Откуда прут знания?
vadiminfoУ большинчства пока разные: ER и РМД..
Это мы уже тщательно разобрали:
13577413
Вернитесь к теме, наконец-то. И спросите U-gene. У него - разные модели что ли???))) [Внимание. Ловушка]
Предположим, что Вы это не сознательно пропустили, а по невнимательности))

...

Рейтинг:

0 / 0

10.06.2013, 13:54

| Ответить | Цитировать | Написать

Хранение данных с гибкой структурой и запросы к ним

#38292562

vadiminfo

Участник

Откуда: Обнинск

Сообщения: 4 779

Рейтинг: 0 / 0

БредятинаТо, что модель данных должна быть одна и та же на концептуальном и логическом уровнях - это просто очевидно)) Для всех.

Самоучек?
Ить до этого считалось, что на логическом должна быть лучшая для логического.
И в общем случае, для разных проектов это могут быть разные типы МД в общем случае. И на момент концептуального проектирования, может быть, не известно какая именно подойдет для логического.

Я уже не говорю про то, что "очевидное для всех" предполагает, что эта одна будет лучшей среди всех уконцептуальных при концептуальном проектировании, и среди логических при логическом. И с какого перепугу это может быть очевидно?
Такая теорема не известна, а вот обратные про комбайны, как бы слышали.

БредятинаvadiminfoУ большинчства пока разные: ER и РМД..
Это мы уже тщательно разобрали:

И что они меньше стали использоваться после Ваших разборок? Тем более что:

БредятинаМы же уже договорились, что я - идиот и впариваю ахинею))

...

Рейтинг:

0 / 0

10.06.2013, 14:17

| Ответить | Цитировать | Написать

25 сообщений из 257, страница 9 из 11

все

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=35&msg=38291937&tid=1552457]:	0ms
get settings:	11ms
get forum list:	14ms
check forum access:	3ms
check topic access:	3ms
track hit:	31ms
get topic data:	12ms
get forum data:	3ms
get page messages:	66ms
get tp. blocked users:	1ms
others:	13ms

total:	157ms