Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 8 [9] 10 11   вперед  Ctrl      все
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
PSV100
Member

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

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

Но, всё таки, вынужден обратить внимание. Пусть "накладная" задана в виде "прикладной модели пользователя":
Накладная:
  	Номер      => STRING
	Дата  	   => DATETIME
	Поставщик  => INTEGER
	...
	Содержимое:
		Товар  => INTEGER
		Цена   => CURRENCY
		Сумма  => CURRENCY
		...

В каком-нибудь ООП-языке для программы эту модель могут определить как-то так:
struct Накладная
{ 	Номер:      STRING;
	Дата:  	    DATETIME;
	Поставщик:  INTEGER;
	...
	struct Содержимое
	{ 	
		Товар:   INTEGER;
		Цена:    CURRENCY;
		Сумма:   CURRENCY;
		...
	}
};

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

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

Иными словами, в RxO классы выражают прикладные сущности и, получается, одновременно и физическую организацию данных. О возможных последствиях был смежный пост.
8 июн 13, 14:06    [14409736]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
PSV100
Member

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

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


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


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

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


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

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

Итак, приступим. Согласно методике RxO нам достаточно выразить прикладные сущности:
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 нам поможет:

-- теперь общие документы такие:
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: "ни о чем больше думать не надо. Нет никаких "отдельных хранилищ для классов", про которые отдельно думать надо. Нет никакой отдельной "физической модели")

Документы на складе будут появляться? (лично я уверен что нет. И я так и не смог решить эту задачу, с учётом того, чтобы не было нигде никакого дублирования данных, всё везде оптимально, красивенько, и прикладная модель причёсана)
8 июн 13, 14:32    [14409789]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
PSV100
U-gene
Ок. А дальше все гораздо проще. Где-нибудь делаем

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


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


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

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


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

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

Итак, приступим. Согласно методике RxO нам достаточно выразить прикладные сущности:
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 Акты

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


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

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

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

Дальше, мне показалось, то же самое.
8 июн 13, 18:10    [14410059]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
PSV100
Здесь тогда нужно говорить о концептуальных ошибках именно конкретной реализации или типовых технологий, а не в целом, что ORM - это ошибка природы.

ORM (где под О понимается семантический аспект, в первую очередь) - объективная необходимость. Так как прямое использование РМД невозможно. Это не значит, вероятно, что РМД - ошибка природы. Собственно, U-gene и доказывает, что РМД - не ошибка, обходясь, как он уверяет, без ORM.
9 июн 13, 10:03    [14411084]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
vadiminfo
PSV100
тип моделей может быть один и тот же. .

Это означает, что может быть и разным.

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

Мы же уже договорились, что я - идиот и впариваю ахинею))
Однако, то, что семантически развитая логическая МД может использоваться, как концептуальная - это просто факт, к сожалению. То есть, идиоты, иногда,оказываются правы))
9 июн 13, 10:06    [14411087]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

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

Вы напрасно добавили физический уровень. Ведь речь шла только о проектировании (на основе МД в первом смысле, по дейту) и использовании МД во втором смысле, по Дейту (независимо от физической реализации данных). При использовании "реляционных систем" архитектура "модель верхнего уровня+маппинг+РМД" неизбежна. Если только не заменить РМД на модель EAV или использовать разработку U-gene))
9 июн 13, 10:13    [14411093]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

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

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

Это точно. Между ними непреодолимая пропасть))
9 июн 13, 10:20    [14411098]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

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

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

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

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

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

U-gene, пожалуйста, поправьте, если что не так.[/quot]
9 июн 13, 10:30    [14411106]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Бредятина,

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

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

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

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

Если Вы согласны с такой трактовкой этих двух терминов, то можно будет продолжить.
9 июн 13, 13:21    [14411250]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
U-gene
Нет, пока с терминами не разберемся, дальше разговаривать смысла нет.

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

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

Конечно! Согласен! Я уже продолжил - см. вопрос выше.
9 июн 13, 14:48    [14411327]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Бредятина
... я - ... впариваю ахинею))

Еще бы.

Бредятина
Однако, то, что семантически развитая логическая МД может использоваться, как концептуальная - это просто факт, к сожалению.

Если эта " семантически развитая логическая МД " хуже на логическом уровне РМД (а это так пока длится реляционная эпоха), а тем более и ER , судя по всему, лучшая на концептуальном, то хоть "семантически развитая" и может, но кому это надо.
Таких семантически развитых предлагалось в свое время. Так и остались чисто академическими.
Т.е. не должна БД использовать такую "семантически развитая логическая МД", если она хуже на логическом уровне РМД, скорее всего.
"Я могу есть только лучший обед. Я не могу есть гадкого обеда" (С) Гоголь "Хлестаков"
9 июн 13, 18:43    [14411795]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
vadiminfo
Еще бы.

Что РМД - ошибка природы? Быстро согласились, на этот раз))
vadiminfo
Если эта " семантически развитая логическая МД " хуже на логическом уровне РМД (а это так пока длится реляционная эпоха),

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

Тем, кто впаривает РМД, конечно, не надо)) А те, кому впаривают, просто ни о чем не знают.
vadiminfo
Таких семантически развитых предлагалось в свое время. Так и остались чисто академическими.

Говорите конкретно, какие МД верхнего уровня Вы хотите добавить к М0-М5. Что там предлагалось, и в какое время))
vadiminfo
Т.е. не должна БД использовать такую "семантически развитая логическая МД", если она хуже на логическом уровне РМД, скорее всего.

Не скорее всего, а абсолютно точно.
vadiminfo
"Я могу есть только лучший обед. Я не могу есть гадкого обеда" (С) Гоголь "Хлестаков"

Который врал, периодически. Впаривал РМД, своего рода, так сказать))
10 июн 13, 00:28    [14412574]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
mad_nazgul
Member

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


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

<:o)
10 июн 13, 07:43    [14412823]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Бредятина
Быстро согласились, на этот раз))

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


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



Бредятина
Факт, что это не так.
На логическом уровне РМД уступает по всем аспектам.

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

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

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

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


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

РМД может быть по производительности могут где-то потеснить. Но по логике пока что не видно ничего.
10 июн 13, 08:30    [14412895]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
mad_nazgul
Ее не "впаривают", просто альтернатив нет, в принципе.

И чтобы впаривать вот так и учат в университетах. Вот, видите, и Вас так научили))
mad_nazgul
Для РМД есть конкретная реализация - SQL.

Бесполезная реализация.
14026636
За 30 лет нашел лишь одно ясное применение алгебре, когда она органично сочетается с семантикой.
mad_nazgul
Которая (реализация) с одной стороны проста, с другой достаточно мощная и гибкая, что покрывает почти весь класс задач.

Заблуждение. Практически, ни одной задачи)) Поэтому и приходится применять архитектуру "модель+маппинг+РМД", часто даже не РМД, а EAV.
10 июн 13, 08:44    [14412937]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
vadiminfo
Почему на это раз? Давно согласен с этим

Что РМД - ошибка природы? Это новость для меня))
vadiminfo
Угу. Только тем кто 30 лет назад ошибся выбрав не РМД, теперь рассуждать про аспекты. Смешно.

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

Не "им", а "вам".
vadiminfo
Даже ошибок у Дейта им не удается найти.

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

То, что модель данных должна быть одна и та же на концептуальном и логическом уровнях - это просто очевидно)) Не нужны никакие попытки, чтобы что-то абсолютизировать. Вернитесь к теме. наконец-то. И спросите U-gene. У него - разные модели что ли???))) [Внимание. Ловушка]
vadiminfo
РМД может быть по производительности могут где-то потеснить. Но по логике пока что не видно ничего.

Конечно, конечно. Так ведь научили))
10 июн 13, 08:56    [14412956]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
vadiminfo
Member

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

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


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

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


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



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

Оно и видно. "Знание" так и прет.


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


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



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

Да уж спасибо, что не как ЧАЛа научили.
10 июн 13, 09:46    [14413201]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Yo.!
Guest
Бредятина
Бесполезная реализация.
14026636

полезная. и вы это увидите когда поработаете более года. алгоритмы обработки OLTP транзакций меняются с годами и ростом данных. данные в OLTP растут экспоненциально, системы типа MUPS, не способные подгонять алгоритмы обработки данных на лету ушли на свалку истории безвозвратно.
имхо после разочарования ИТ индустрии в ОО подходах, РМД будет искать варианты замены процедурных расширений на какую-то декларативную хрень.
10 июн 13, 10:49    [14413516]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
Yo.!
полезная. и вы это увидите когда поработаете более года. алгоритмы обработки OLTP транзакций меняются с годами и ростом данных. данные в OLTP растут экспоненциально, системы типа MUPS, не способные подгонять алгоритмы обработки данных на лету ушли на свалку истории безвозвратно.

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

Я детально пояснял про то, что подходы, основанные на ООП, просто не имеют к БД никакого отношения. Разумеется, разочарование))
10 июн 13, 12:12    [14414065]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
vadiminfo
Любой может убедиться,

Что РМД - ошибка природы? Разумеется. Это я честно копирую Ваш стиль обсуждения вопросов по существу, вероятно, общепринятый на sql.ru. Видите, стараюсь, учусь))
Мы же уже договорились, что я - идиот и впариваю ахинею)) Вот, пытаюсь понять Ваше мнение о системе U-gene.
vadiminfo
Оно и видно. "Знание" так и прет.

Вроде U-gene про БЗ не говорил. Из какой части системы оно прет?
vadiminfo
Ну, разве, для тех для кого между уровнями разницы нет. "Должна быть" одна и таже модель повидмому, потому уровни ничем не "должны" отличаьтся. Иначе как бы и модели могут отличаться, скорее всего.

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

Вернитесь к теме. наконец-то. И спросите U-gene. У него - разные модели что ли???))) [Внимание. Ловушка]
Предположим, что Вы это не сознательно пропустили, а по невнимательности))
10 июн 13, 12:20    [14414125]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Yo.!
Guest
Бредятина
Наивно)) Мягко говоря. Поработал с БД более 30 лет. MUMPS, к моему великому сожалению, остается единственной пригодной средой создания и эксплуатации БД, в том числе, именно потому что легкость "подгонки алгоритмов" превосходит "реляционные системы" настолько, что даже сравнивать не имеет смысла.

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

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

не имеют. а кто-то с этим спорит ?
10 июн 13, 12:33    [14414242]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Бредятина
Что РМД - ошибка природы?

Это Вашу мечту Вы пытались подбросить вместо единственной удачной Вашей мыстли:

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



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


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


Бредятина
У него - разные модели что ли???)))

У большинчства пока разные: ER и РМД..
10 июн 13, 12:56    [14414441]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
Yo.!
вериться с трудом, ваши рассуждения выдают в вас то, что вы не сталкивались с системами где через год данные выросли по экспоненте и алгоритмы, что были наиболее оптимальны на этих же данных год назад совершенно не годятся.

Мне остается только адекватно отвечать - я уверен, что Вы никогда не сталкивались.
Yo.!
не имеют. а кто-то с этим спорит ?

Отлично. У U-gene классы не из ООП?
10 июн 13, 13:48    [14414823]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
vadiminfo
Это Вашу мечту Вы пытались подбросить вместо единственной удачной Вашей мыстли

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

То, что модель данных должна быть одна и та же на концептуальном и логическом уровнях - это просто очевидно)) Для всех.
У U-gene не БЗ. Откуда прут знания?
vadiminfo
У большинчства пока разные: ER и РМД..

Это мы уже тщательно разобрали:
13577413
Вернитесь к теме, наконец-то. И спросите U-gene. У него - разные модели что ли???))) [Внимание. Ловушка]
Предположим, что Вы это не сознательно пропустили, а по невнимательности))
10 июн 13, 13:54    [14414884]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
vadiminfo
Member

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

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


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



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

Это мы уже тщательно разобрали:

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

Бредятина
Мы же уже договорились, что я - идиот и впариваю ахинею))
10 июн 13, 14:17    [14415063]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 8 [9] 10 11   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить