Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 [11] 12 13 14 15 .. 51   вперед  Ctrl
 Re: Закат RDBMS?  [new]
мод
Guest
Сахават Юсифов
вот я ввожу конкретный гвоздь в БД. Ну, на фига мне "крепеж", "вид крепежа"...? Да я знать об этом не хочу. А вот кому надо, тот пусть и думает, относится ли гвоздь к крепежу или хранится как вещдок. Зачем мне лишние знания?

Обычно при вводе объекта его сразу классифицируют, но наверное можно этот процесс растянуть. Главное что бы в рез-те все было заполнено.
24 сен 07, 17:36    [4708007]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Сахават Юсифов
Member

Откуда: Орел
Сообщений: 3992
ModelR
Это напоминает возмущение зубров Ассемблера типизацией переменных в ЯП.
Какая тебе разница, целое или вещественное ?! Моя ячейка, как хочу, так и использую!

Да. Сприал закручивается вниз.
24 сен 07, 18:42    [4708360]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Сахават Юсифов
Member

Откуда: Орел
Сообщений: 3992
мод
Сахават Юсифов
вот я ввожу конкретный гвоздь в БД. Ну, на фига мне "крепеж", "вид крепежа"...? Да я знать об этом не хочу. А вот кому надо, тот пусть и думает, относится ли гвоздь к крепежу или хранится как вещдок. Зачем мне лишние знания?

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


Кому надо, тот заполнит чего хочет, получив сообщение.
24 сен 07, 18:46    [4708372]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
okdoky
Member

Откуда:
Сообщений: 349
U-gene
okdoky
Осмысленность зависит от человека. Наконец-то. Лед тронулся. Неужели Вы соглашаетесь, что имя атрибута может и должно определять тип, как минимум для самого человека? В БД часто используются одни и те же имена атрибутов, например возраст, пол и т.д. Они имеют вполне определенные значения и могут контролироваться не только человеком, но самой СУБД (date, number и тд). Об этом была речь. Ну и конечно о том, что имя атрибута само может (и должно) определять тип
Подождите. Дайте разобраться. То есть, по Вашему, date и number - это домены существующие в РСУБД, а возраст и пол - это артибуты,которые должны определять тип. Так что-ли?
Нет, типы date и number также могут использоваться как атрибуты соответствующих типов date и number. При определении таблицы Вам достаточно использовать такое выражение
CREATE TABLE CONTRACT(NUMBER, DATE, …), 
без повторений типа
CREATE TABLE CONTRACT(NUMBER NUMBER,  DATE DATE, …)
.

Речь идет о том, что в современных РСУБД пока используется достаточно ограниченное количество типов. Все они в основном соответствуют спецификации SQL. В ОРСУБД количество типов может быть неограниченное, но разработчик вынужден создавать их сам, вместо того чтобы использовать готовые, например такие как AGE, SEX.
25 сен 07, 07:45    [4709239]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
okdoky
Member

Откуда:
Сообщений: 349
U-gene
Не - это не то определение. okdoky спрашивает про атрибуты отношение, а приведенная цитата относится к атрибутам переменных экземпляра объектного типа (т.е. - по простому - к атрибутам объекта) - а это немножко совсем разные вещи.
На сколько и в чем они разные? В ОСУБД Вы определяете переменные (или поля) класса, затем для объектов этого класса задаете значения их переменных (полей). Можно провести аналогию с РСУБД, где в роли переменных выступают атрибуты (или колонки). Сначала вы определяете атрибуты таблицы, затем для каждой записи задаете значения их атрибутов.
25 сен 07, 07:55    [4709249]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
okdoky
Member

Откуда:
Сообщений: 349
ПКН
Вот еще на счет современных определений Основы современных баз данных С.Д. Кузнецов.

Похоже okdoky что-то взял оттуда
Нет я использовал описание языка Zigzag. Там типы и атрибуты не отделяются друг от друга. Можно вообще обходится без типов, как в XML БД.
25 сен 07, 07:57    [4709251]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
okdoky
Member

Откуда:
Сообщений: 349
okdoky
Нет, типы date и number также могут использоваться как атрибуты соответствующих типов date и number.
Исправлю на
автор
Нет, date и number также могут использоваться как атрибуты соответствующих типов date и number.
Чтобы mir не зацепился.
25 сен 07, 08:18    [4709278]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
okdoky
mir
okdoky
Вы понимаете атрибут как переменную
Собственно, все ваши дальнейшие глубокомысленные рассуждения можно смело пропустить, потому что я и страшном сне не догадался бы принять атрибут отношения за переменную
И напрасно. Не ограничивайте себя. Это не дает Вам возможность рассуждать самому и понимать рассуждения других.
О, господина okdoky потянуло на философию? okdoky желает избавиться от пут знания и рассуждать без ограничений? Помедитируйте тогда над простой мыслью о том, что любое знание есть ограничение. Хотите избавить себя от ограничений — избавьте себя от знаний. Вообще. Впрочем, в этом искусстве вам мои советы и не нужны.
okdoky
Атрибут, как и переменная, имеет свое имя и свое значение.
Выражение «значение атрибута» к контексте отношений РМД означает не то же самое, что «значение переменной», хотя по виду и похоже. Атрибуты — это просто такие специальные мнемонические индексы в кортежах (не путать с индексами таблиц в SQL). Они играют в формальном смысле ровно ту же роль, что и обычные порядковые номера. Вот здесь, в этой же теме, я изволил читать мини-лекцию на эту тему. Но вы такой примечательный борец с ясностью и определенностью, что любые объяснения, видимо, вылетают у вас из головы на второй день. Или это было «слишкоммногабукафф»? Перечитайте ещё раз. И тогда поймете, что с точки зрения математики никакой разницы нет, как записать кортеж: { (1, Иванов), (2, Иван), (3, Иванович) } или { (Фамилия, Иванов), (Имя, Иван), (Отчество, Иванович) }. Однако в первом случае вам и в голову не придёт говорить, что целые числа 1, 2, 3 — это переменные, а, например, «Иванов» есть значение числа 1. Но точно так же и во втором варианте записи «Иванов» не есть значение атрибута Фамилия. Когда говорят «значение атрибута», то это следует понимать как упрощение, под коим подразумевается «значение кортежа, индексированное данным атрибутом», или «значение кортежа, ассоциированное с данным атрибутом». Заметьте, что именно значение кортежа, а не просто любое значение домена. То есть вне кортежа никакого «значения атрибута» нет и быть не может, это бессмыслица. Вне кортежей можно говорить лишь о значениях, входящих в домены (составляющих домены). А вот у переменных всё иначе. Переменная есть «носитель» значения. Переменная как понятие вполне самодостаточна и неопределима (аксиоматична).
Короче, ещё раз: фразы «значение переменной» и «значение атрибута» по форме идентичны, но по сути совершенно различны.
okdoky
mir
okdoky
Об этом Вам говорили.
О чём «об этом»?
Не уходите в демагогию. Неужели Вы не поняли, о чем Вам говорили?
Если б я понял, я бы ответил. Однако трудно понять человека, кредо которого — борьба с ясностью суждений. Это ж вы постоянно пеняете мне, цитирую: «Опять Вас на четкие определения потянуло» ((c) okdoky).
okdoky
mir
okdoky
Почему для таких имен нельзя использовать специальные программы контроля значений атрибута?
Для каких «таких» имён? Осмысленных? Осмысленность зависит от человека. Осмысленность имени программой не проконтролируешь. Какой в точности контроль значений имеется в виду?
Осмысленность зависит от человека. Наконец-то. Лед тронулся.
Боже, какое самодовольство… А вот интересно, где ж это я говорил, что имена атрибутов бессмысленны? Читайте ещё раз, только вдумчиво, цитирую: «С точки зрения идентификации элементов множество {1, 2, 3} ничем не лучше и не хуже множества {Фамилия, Имя, Отчество}. Зато с точки зрения человека, второй вариант понятнее и потому удобнее.» Или: «человеку (повторю) легче помнить и использовать понятные имена атрибутов, чем их порядковые номера.»
Для меня, знаете ли, лед тронулся еще тогда, когда вы слова «лед» не понимали.
okdoky
Неужели Вы соглашаетесь, что имя атрибута может и должно определять тип, как минимум для самого человека? В БД часто используются одни и те же имена атрибутов, например возраст, пол и т.д. Они имеют вполне определенные значения и могут контролироваться не только человеком, но самой СУБД (date, number и тд).
Ага, начали за здравие, кончили за упокой. Начали с радостных восклицаний, что имена атрибутов осмысленны именно для человека, а потом — вывод, что они «могут контролироваться не только человеком, но самой СУБД». Так определитесь, для человека эти имена осмысленны, или для СУБД. Я подскажу, что это несколько не одно и то же.

P.S. Так мы и не дождались вашего комментария по поводу вашей фразы «Кстати на счет домена или "типа" в понятии реляционщиков (последний термин они тупо взяли из объектных моделей).». Поясните, кто, когда, у кого и что тупо спёр.
26 сен 07, 17:54    [4719938]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
okdoky
U-gene
okdoky
Осмысленность зависит от человека. Наконец-то. Лед тронулся. Неужели Вы соглашаетесь, что имя атрибута может и должно определять тип, как минимум для самого человека? В БД часто используются одни и те же имена атрибутов, например возраст, пол и т.д. Они имеют вполне определенные значения и могут контролироваться не только человеком, но самой СУБД (date, number и тд). Об этом была речь. Ну и конечно о том, что имя атрибута само может (и должно) определять тип
Подождите. Дайте разобраться. То есть, по Вашему, date и number - это домены существующие в РСУБД, а возраст и пол - это артибуты,которые должны определять тип. Так что-ли?
Нет, типы date и number также могут использоваться как атрибуты соответствующих типов date и number. При определении таблицы Вам достаточно использовать такое выражение
CREATE TABLE CONTRACT(NUMBER, DATE, …), 
без повторений типа
CREATE TABLE CONTRACT(NUMBER NUMBER,  DATE DATE, …)
.

2 Okdoky Вы мыслите какими то недоступными машине категориями. Например, что значит "часто используется"? Как она будет разбираться, как имя сейчас используется? Типа "с вероятностью 60% это имя типа но может быть это имя переменной, куда забыли добавить тип"?

Что значит "контролироваться самой СУБД"? Если речь идет о контроле значений тех или иных атрибутов кортежей, то я, честно, не понимаю, с чем Вы боретесь. В теории это никак не ограничивается (домены могут быть какие угодно и как угодно унутри себя контролируемые), все ребята отчаянно согласны, что это полезно, на практике это тоже уверенно рнеализуется. В общем - мужики не против. Причем уже давно. Если речь идет о чем то еще - то я тогда не понимаю о чем.

Кстати, примеры выглядят неубедительно - например я для контракта насчитаю как минимум три поля типа DATE - дата заключения, даты начала и окончания действия. И нафига мне Ваше нововведение здесь будет нужно? Я скорее предпочту всегда использовать отдельно имя переменной и отдельно имя типа - точно так же как, например в VBA, при наличии возможности неаявного определиния переменных я всегда эту возможность запрещаю использовать (а ведь те кто эту возможность делал, хотели как лучше - пару строк сэкономить ). Нет я согласен, можно и
CREATE TABLE CONTRACT(NUMBER, DATE, …), 
(транслятору это переварить ничего не стоит) но выгоды особой здесь не вижу. В любом случае это означает лишь, что опреляется атрибут имя которого совпадает с именем имеющегося типа. Но писать "атрибут определет тип" в любом случае неверно. Наоборот надо.

Более обще, возникает впечатление, что вы идете не в том направении - взяв какие-то системы и какие-то языки Вы начинаете на их основе строить типа глобальные концепции (которые, кстати, на поверку оказываются заморочками трансляционного уроня имеющими сомнительную нужность). Но КМК надо идти в обратно направлении. В любом случАе - неполохо было бы с этими концепцими ознакомиться.

okdoky
Речь идет о том, что в современных РСУБД пока используется достаточно ограниченное количество типов. Все они в основном соответствуют спецификации SQL. В ОРСУБД количество типов может быть неограниченное, но разработчик вынужден создавать их сам, вместо того чтобы использовать готовые, например такие как AGE, SEX.
Опана! например в MS SQL 2000 который, как не трудись, к ОРСУБД не отнесешь, я могу определить и использовать сколько угодно разных типов (что впрочем не значит "какие угодно" ;).

И что значит - "вынужден создавать"? А куда деться-то? КМК программирование - это, по большому счету, и есть создание типов. Вы что, нас без работы оставить хотите? :)
26 сен 07, 19:23    [4720413]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
okdoky
U-gene
Не - это не то определение. okdoky спрашивает про атрибуты отношение, а приведенная цитата относится к атрибутам переменных экземпляра объектного типа (т.е. - по простому - к атрибутам объекта) - а это немножко совсем разные вещи.
На сколько и в чем они разные? В ОСУБД Вы определяете переменные (или поля) класса, затем для объектов этого класса задаете значения их переменных (полей). Можно провести аналогию с РСУБД, где в роли переменных выступают атрибуты (или колонки). Сначала вы определяете атрибуты таблицы, затем для каждой записи задаете значения их атрибутов.
Повторяю: взяв какие-то системы и какие-то языки Вы начинаете на их основе строить типа глобальные концепции. Добавлю: Исходя из сходства языковых конструкция Вы уверенно говорите об существовании концептуальных аналогий. Это неверно.
26 сен 07, 19:26    [4720428]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
okdoky
ПКН
Вот еще на счет современных определений Основы современных баз данных С.Д. Кузнецов.

Похоже okdoky что-то взял оттуда
Нет я использовал описание языка Zigzag. Там типы и атрибуты не отделяются друг от друга. Можно вообще обходится без типов.
Я предпочту обходиться без ZigZag'a. И, кстати, в таком случае как же там различить дату начала контракта и дату его окончания?
26 сен 07, 19:29    [4720445]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
okdoky
Исправлю на .... Чтобы mir не зацепился.
Что то мне подсказывает, что попытка не удалась
26 сен 07, 19:30    [4720451]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
мод
Guest
U-gene
И, кстати, в таком случае как же там различить дату начала контракта и дату его окончания?

CREATE TABLE CONTRACT(NUMBER, DATE, DATE, DATE)
SELECT 4,3,2,1 FROM CONTRACT
это обыкновенный двухмерный массив (okdoky ломится в давно открытую дверь)
27 сен 07, 10:08    [4721879]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
ПКН
Guest
мод
U-gene
И, кстати, в таком случае как же там различить дату начала контракта и дату его окончания?

CREATE TABLE CONTRACT(NUMBER, DATE, DATE, DATE)
SELECT 4,3,2,1 FROM CONTRACT
это обыкновенный двухмерный массив (okdoky ломится в давно открытую дверь)
Где здесь начало и конец? Можно использовать
CREATE TABLE CONTRACT(NUMBER, DATE, BEGIN DATE, END DATE)
где BEGIN DATE, END DATE - подтипы. Пока пользователь их не определил их значения могут совпадать с DATE.
Дальше
SELECT NUMBER, DATE, BEGIN DATE, END DATE FROM CONTRACT 
или
SELECT NUMBER, DATE, BEGIN, END FROM CONTRACT
где BEGIN, END - сокращенные наименования переменных соответствующих типов
27 сен 07, 19:35    [4726935]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
мод
Guest
ПКН

Нет слов (одни выражения)
28 сен 07, 10:10    [4728434]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
shuklin
1024
а объектщики сами себе боятся признаться что все их обращения к объектам транслируются в нормальный SQL

Наглая ложь )))) В Cerebrum нету SQL. У меня "язык" запросов является объектной моделью.
И таблицы в Cerebrum вовсе не отношения а коллекции узлов графа.

Возможно, когда говорят об объктщиках имеют что-то большее, чем Селебрум или Зигзаг, коиея менее известны даже чем Клиппер, у которого тоже типа "нету" SQL.
В связи с этим, все еще представляется преждевременным доказанность ложности утверждения о настоящих объектщиках. Разве что можно говорить только о том, что некоторые выдающие себя за объетщиков, могут транслировать не в нормальный SQL, а, например, в что-то клипперноподобное.
28 сен 07, 12:54    [4729739]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Сахават Юсифов
Member

Откуда: Орел
Сообщений: 3992
vadiminfo
В связи с этим, все еще представляется преждевременным доказанность ложности утверждения о настоящих объектщиках.


У меня вопросы были простые.
В РМД и ООП сначала задаются множества (коллекции) и определеяются операции над ними.
Структура этих множеств жесткие. Несмотря на то, что элементы этих множеств могут принадлежать разным множествам доступ к элементу осуществляется только через первичное множество.
Структуру трудно безболезненно эволюционировать с учетом совместимости.
Транзакционность и оповещение не включены в систему изначально.
28 сен 07, 14:25    [4730597]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Сахават Юсифов
vadiminfo
В связи с этим, все еще представляется преждевременным доказанность ложности утверждения о настоящих объектщиках.


У меня вопросы были простые.
В РМД и ООП сначала задаются множества (коллекции) и определеяются операции над ними.
Структура этих множеств жесткие. Несмотря на то, что элементы этих множеств могут принадлежать разным множествам доступ к элементу осуществляется только через первичное множество.
Структуру трудно безболезненно эволюционировать с учетом совместимости.
Транзакционность и оповещение не включены в систему изначально.

Я про другое писал. Про подозрения о маппировании ООМД на РМД в ООСУБД.
А так, естественно, обе МД относятся к структурированным. Может быть ООМД более выразительна (менее однородна, содержит поведение), но в плане манипулирования данными РМД имеет сильную сторону - декларативность и ассоциативность (против имеративности и навигационности). А ведь мы БД созданем, чтобы быстро получать нужную инфу (мало толку напихать в БД, если извлечь нужное сложно). Да и простота проектирования РМД имеет значение.
Про доступ через "первичное" множество не въехал, что за этим скрывается.
Эволючионировать структуру естественно трудно, так она в силу природы понятия "структура" - нечто статичное.
Это вопросы достоинства сильнотипизированных и слаботипизированных МД.
В сильнотипизированные сложно запихивать реальный мир в общем случае, а из слаботипизированных сложно извлекать нужную инфу.
28 сен 07, 15:22    [4731153]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 Сахават Бывают системы мономорфные(один тип - одна спецификация), бывают полиморфные (много типов - одна спецификация). А Вы хотите антиморфную замутить :) Типа, бесформенные типы :)
28 сен 07, 15:56    [4731431]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
всем сестрам по серьгам
Guest
U-gene
2 Сахават Бывают системы мономорфные(один тип - одна спецификация), бывают полиморфные (много типов - одна спецификация). А Вы хотите антиморфную замутить :) Типа, бесформенные типы :)


Поддерживаю.
Сахават, проблема внесения изменений нисколько не отменяет типизированность. Упростить внесение изменений можно, но должна быть метамодель, формальные операции изменения модели, формирование БД, интерефейса, клиентского и серверного кода по новой модели с автоперекомпиляцией, перенесение данных из старой модели в новую.
Такой системы нет, и сделать ее сложно (но можно, и все для этого есть), но и никакого другого адекватного пути неизвестно. Отмена типизации – путь вникуда.
Таково мое мнение.
28 сен 07, 17:36    [4732289]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
В общем, Сахават, Вы тоже все спутали.

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

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

Хотя типизация в СУБД нужна конечно. Ну прикиньте - если Ленинскую библиотеку разобрать по листикам, то получиться большая куча макулатуры. Даже если книги не рвать, а просто перемешать, то получится большая бестолковая гора книг. СУБД без типов КМК то же самое.
28 сен 07, 17:41    [4732335]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Добавлю - в РМД ничего не говорит о том. что и как задается. Проще надо быть - для того, что бы оперировать отношениями, они должны просто существовать - для РМД этого достаточно. Применительно к системе это означает, что отношения могут быть заданы и неяно (т.е. безо всяких явно написанных CREATE TABLE ). И вот когда до более широкого круга людей это допрет, то (квази)проблема совмещения ОО и РМ улетучиться сама собой - потому что ее реально нет.
28 сен 07, 17:52    [4732421]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Сахават Юсифов
Member

Откуда: Орел
Сообщений: 3992
U-gene
Добавлю - в РМД ничего не говорит о том. что и как задается. Проще надо быть - для того, что бы оперировать отношениями, они должны просто существовать - для РМД этого достаточно. Применительно к системе это означает, что отношения могут быть заданы и неяно (т.е. безо всяких явно написанных CREATE TABLE ). И вот когда до более широкого круга людей это допрет, то (квази)проблема совмещения ОО и РМ улетучиться сама собой - потому что ее реально нет.

В общем надо иметь в одном флаконе - О (объектное хранилище с автоматической типизацией и танзакционностью) + ОО (с жесткой типизацией с системой оповещения) + РМ (с временной типизацией).
29 сен 07, 02:42    [4733947]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
U-gene
Применительно к системе это означает, что отношения могут быть заданы и неяно (т.е. безо всяких явно написанных CREATE TABLE ).
Кстати, таковые и сейчас встречаются. Это подвыражения в запросах. Это Common Table Expressions. Тоже ведь отношения и тоже без всяких CREATE TABLE.
1 окт 07, 16:48    [4739743]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
AlexTheRaven
Member

Откуда: Москва
Сообщений: 879
Заката RDBMS не вижу, да и не будет его. Таблицы замечательно подходят для хранения информации о большинстве сущностей окружающего мира.
Не верите? Допустим, Вам нужно вывести информацию об экземплярах на экран. Для пользователя. Ваша первая мысль? Таблица. А что мешает так хранить?

В мире очень мало физических вещей, для которых нужны сложные связи, множественные наследования и т.д. Большинство таких вещей имеют искусственное происхождение. Насколько я знаю, ООСУБД в основном применяются либо из-за необходимости хранить информацию о сложных вещах (САПР), либо из-за лени и нежелания программистов изучать ERD и SQL (типа и в виде объектов очень удобно, а гигагерцы с гигабайтами всё простят).

Изящные абстракции и алгоритмы - это, конечно, замечательно, но обычно приводят к тому, что на практике это не работает, а автор не может найти ошибки.
1 окт 07, 19:24    [4740568]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 [11] 12 13 14 15 .. 51   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить