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

Откуда: Орел
Сообщений: 3992
U-gene
2 Сахават Смысл предыдущего высказывания не уловил. Понятно, что за интернационал (как и все тут), но что что конкретно? :)

На всякий случай осторожно замечу, что для меня имя класса значит не только (и даже не столько) обозначение структуры, как имя некого множества. Не знаю как Вам, но мне интересно работать не только с отдельными объектами, но и с множествами таких объектов. Вот я и задаю изначально в системе, что де "Пусть существует множество" и уж потом "пусть у его элементов есть структура". А уж что там вложено и\или как оно агрегировано - это пусть система переваривает:)


а я за то, что бы сначала были объекты (клентские), а потом клиенты могли бы эти объекты включить в множества (клиентские).
19 сен 07, 11:14    [4687025]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Сахават Юсифов
Member

Откуда: Орел
Сообщений: 3992
ModelR
Ничего, я вмешаюсь?
Я понимаю Сахавата так, что желательно первично создать некий объект, а затем предоставить возможность абсолютно произвольно и равноправно включить (исключить, перенести?) его в любую категорию. При этом видимо все же должен быть какой-то механизм разрешения коллизий/ предотвращения бреда ?
Типизированный же подход как раз требует (в сугубо благих целях предотвращения бреда) сначала сконструировать категории, а затем создавать объект непосредственно относящийся ровно к одной категории, и лишь в силу наследования категорий - к каким то-другим. Множественное наследование вообще проблема, лишь частично обходимая интерфейсами.[/quot]

Точно. :)
19 сен 07, 11:16    [4687035]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
мод
Guest
Gluk (Kazan)
так более понятно ?

Да, так понятнее. Но есть замечания:
1. Наиболее продвинутые ЯП это не ООП
2. Многопоточность в ЯП практически не реализована - есть только самафоры, но нет изоляции и всего, связанного с понятием транзации а потребность в этом есть (см. данный форум)
3. Понятие постоянного хранения относительно - см. временные таблицы.
Итого: необходима настоящая интеграция ЯП+СУБД а не нынешнее противостояние.
зы а как вам идея рассматривать СУБД Oracle как систему управления данными языка pl/sql
19 сен 07, 11:52    [4687349]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
мод
Да, так понятнее. Но есть замечания:
1. Наиболее продвинутые ЯП это не ООП
2. Многопоточность в ЯП практически не реализована - есть только самафоры, но нет изоляции и всего, связанного с понятием транзации а потребность в этом есть (см. данный форум)
3. Понятие постоянного хранения относительно - см. временные таблицы.
Итого: необходима настоящая интеграция ЯП+СУБД а не нынешнее противостояние.
зы а как вам идея рассматривать СУБД Oracle как систему управления данными языка pl/sql


Честно говоря тема дискуссии не интересна, но ладно

1. Уточните список продвинутых ЯП и определения OO в отношении ЯП
2. Семафоров в языке нет, они в системных библиотеках. В языке (Ада) есть рандеву :). Предложения по реализации различного рода транзакций/изоляций неоднократно появляются, но совершенно не востребованны на практике. В качестве примера нелюбимый мной именно за эту заумь Джефф Элджер
3. Понятие постоянного хранения я расшифровал чуть выше в этой или соседней ветке. К вечному хранению оно имеет такое же отдаленное отношение как и к временным таблицам очищаемым по commit (в Oracle)
19 сен 07, 12:09    [4687480]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
U-gene
Member

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

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

Так?
19 сен 07, 12:51    [4687818]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Сахават Юсифов
Member

Откуда: Орел
Сообщений: 3992
U-gene
2 Сахават

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

Так?


1. Описали объект. (ввели ИД, и из словаря взяли свойства).
2. Если НАДО, то сохранили именованный шаблон.
3. Вводим другой объект, если он какой-то родственник предыдущего объекта, то вызываем шаблон, удаляем лишнее, добавляем нужно и сохраняем. Если надо, то п2.
4. Если надо, то вводим классифицирующий признак , добавляем ИД объекта в коллекцию.

Я у себя ввел базовый шаблон (ИД, Наименование, Обозначение, Код, Описание).

Всегда можно менять и шаблон и структура отдельного объекта. Шаблон - просто предложение. Объект не объязан точно следовать шаблону (но по шаблону можно найти все изначально сопоставленные объекты и наоборот, даже если ничего общего у них уже нет.)
Ничего ни у кого наследовать не надо.
И систему менять не надо. Объектный шаблон в системе не зафиксирован.
19 сен 07, 13:33    [4688150]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Стоун Брейкер
Winnipuh
But Stonebraker now argues that relational databases, also known as RDBMSes, are "long in the tooth" and "should be considered legacy technology."


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

Что касается колоночных БД, то это не просто изменение формата хранения, а изменение взгляда на данные. При таком подходе мы видим прежде всего размерности (колонка это размерность), что к реляционности не имеет никакого отношения.


Экая редкостная ересь. Sybase IQ что, не реляционная СУБД? Она как раз и есть column-store а не row-store. "Уж сколько раз твердили миру" что логическая модель данных (т.е. реляционная) и модель физического их хранения (т.е. куча, сбалансированное Б* дерево, или column-store) есть вещи совсем разные. Современные RDBMS с позволяют иметь различные схемы хранения "таблиц" на диске:
- куча (самый распространенный)
- дерево (IOT в оракле)
- хэш-таблица
- кластер (записи из 2х таблиц вместе лежат)
- "вертикальное" хранение (column-store)
итп.

Это не мешает им быть реляционными. У Michael Stonebraker базар про всего-лишь навсего очередной способ физического хранения данных. Давно кстати всем известный, ибо Sybase IQ не вчера появился на свет. Так что учите матчасть.
20 сен 07, 03:00    [4691441]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
ПКН
Guest
Зл0й
Экая редкостная ересь. Sybase IQ что, не реляционная СУБД? Она как раз и есть column-store а не row-store. "Уж сколько раз твердили миру" что логическая модель данных (т.е. реляционная) и модель физического их хранения (т.е. куча, сбалансированное Б* дерево, или column-store) есть вещи совсем разные.
тогда любую бд можно назвать реляционной
20 сен 07, 04:04    [4691456]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
ПКН
Зл0й
Экая редкостная ересь. Sybase IQ что, не реляционная СУБД? Она как раз и есть column-store а не row-store. "Уж сколько раз твердили миру" что логическая модель данных (т.е. реляционная) и модель физического их хранения (т.е. куча, сбалансированное Б* дерево, или column-store) есть вещи совсем разные.
тогда любую бд можно назвать реляционной
Назвать-то можно. Но это лишь будет характеризовать уровень знаний "признающего". И в первую очередь покажет, что "признающий" ничего не понимает в теории БД.
20 сен 07, 07:13    [4691526]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Отвлекся
Guest
okdoky
Адептам реляционного трудно понять, что не только домен, но и атрибут может являться типом. То есть мы можем говорить отдельно о типе "сотрудник" и о типе "начальник", хотя значения у них могут быть общими. Здесь mir-у придется поднапрячься.
Согласен, интересная мысль. Получается атрибут, это подтип более общего типа (домена), также как атрибут "возраст" и домен "число". Только атрибут мы не рассматриваем отдельно. То есть мы можем говорить о возрасте сотрудника и о возрасте планеты, где сотрудник и планета фактически обозначают отношение. Дальше можно конкретизировать или сужать область значений типа. Очевидно такой подход будет применяться, но только в будущих СУБД (СУБЗ), понимающих ЕЯ. То есть каждое слово (или их комбинацию) можно рассматривать как определенный тип.
20 сен 07, 09:59    [4691905]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Отвлекся
okdoky
Адептам реляционного трудно понять, что не только домен, но и атрибут может являться типом. То есть мы можем говорить отдельно о типе "сотрудник" и о типе "начальник", хотя значения у них могут быть общими. Здесь mir-у придется поднапрячься.
Согласен, интересная мысль. Получается атрибут, это подтип более общего типа (домена), также как атрибут "возраст" и домен "число". Только атрибут мы не рассматриваем отдельно. То есть мы можем говорить о возрасте сотрудника и о возрасте планеты, где сотрудник и планета фактически обозначают отношение. Дальше можно конкретизировать или сужать область значений типа. Очевидно такой подход будет применяться, но только в будущих СУБД (СУБЗ), понимающих ЕЯ. То есть каждое слово (или их комбинацию) можно рассматривать как определенный тип.
Секрет прост: если атрибут имеет дополнительные ограничения по отношению к своему домену (типу), значит этот домен (тип) атрибута определён неправильно и требует переопределения. Связи "тип-подтип" могут (и должны) существовать между доменами, но каждый атрибут должен быть соотнесен с одним, правильным типом. А то можно из всех доментов оставить только один QLEVariant, на нём определить все отношения, а реальные типы атрибутов "Фамилия", "Дата рождения", "Пол" и т.п. помнить "в уме" или задавать как отдельные ограничения. Но это будет просто ошибкой проектирования. Адептам "нереляционного" трудно понять эту простую мысль, им проще нагородить кучу своих "интересных" мыслей по этому поводу.
20 сен 07, 10:39    [4692142]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
mir
А то можно из всех доментов оставить только один QLEVariant, на нём определить все отношения, а реальные типы атрибутов "Фамилия", "Дата рождения", "Пол" и т.п. помнить "в уме" или задавать как отдельные ограничения. Но это будет просто ошибкой проектирования.

Интересно, и в чем же здесь ошибка? В необходимых случаях долой ограничения, здравствуй гибкость, в других случаях привет ограничением, здравствуй непротеворечивость. А скорость и компактность хранения - дело физической реализации.
20 сен 07, 10:48    [4692220]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
shuklin
mir
А то можно из всех доментов оставить только один QLEVariant, на нём определить все отношения, а реальные типы атрибутов "Фамилия", "Дата рождения", "Пол" и т.п. помнить "в уме" или задавать как отдельные ограничения. Но это будет просто ошибкой проектирования.

Интересно, и в чем же здесь ошибка? В необходимых случаях долой ограничения, здравствуй гибкость, в других случаях привет ограничением, здравствуй непротеворечивость. А скорость и компактность хранения - дело физической реализации.
Ошибка будет в том случае, если априорно известные ограничения на множество значений атрибута есть, но они задаются каким угодно способом (в приложении, в триггерах, отдельными декларативными ОЦ, а то и вовсе не задаются), кроме прямого способа: правильно определить соответствующий домен.
20 сен 07, 10:54    [4692254]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Сахават Юсифов
Member

Откуда: Орел
Сообщений: 3992
mir
а то и вовсе не задаются), кроме прямого способа: правильно определить соответствующий домен.


Определите домен для "управление" в ИДЕФ.
20 сен 07, 12:36    [4693234]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Сахават Юсифов
mir
а то и вовсе не задаются), кроме прямого способа: правильно определить соответствующий домен.


Определите домен для "управление" в ИДЕФ.
Платите бабки, определю.
20 сен 07, 15:05    [4694444]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
mir
Ошибка будет в том случае, если априорно известные ограничения на множество значений атрибута есть, но они задаются каким угодно способом (в приложении, в триггерах, отдельными декларативными ОЦ, а то и вовсе не задаются), кроме прямого способа: правильно определить соответствующий домен.

Это даже в теории натянуть науши трудно. На практике же ограничения меняются отражая развитие бизнеса. Если задать ограничения на тип поля на физическом уровне (ваш прямой способ), то любое изменение будет сопряжено с кучей переделок. Это даже не рассматривая случаи, когда такие изменения изначально входят в бизнес сценарий. Не убедительно.
20 сен 07, 18:23    [4696113]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
лач
Guest
mir
shuklin
mir
А то можно из всех доментов оставить только один QLEVariant, на нём определить все отношения, а реальные типы атрибутов "Фамилия", "Дата рождения", "Пол" и т.п. помнить "в уме" или задавать как отдельные ограничения. Но это будет просто ошибкой проектирования.

Интересно, и в чем же здесь ошибка? В необходимых случаях долой ограничения, здравствуй гибкость, в других случаях привет ограничением, здравствуй непротеворечивость. А скорость и компактность хранения - дело физической реализации.
Ошибка будет в том случае, если априорно известные ограничения на множество значений атрибута есть, но они задаются каким угодно способом (в приложении, в триггерах, отдельными декларативными ОЦ, а то и вовсе не задаются), кроме прямого способа: правильно определить соответствующий домен.

Чушь. Полная. Говорит о непонимании автором основ моделирования данных. По степени общности сказать "правильно определите домены" это все равно что сказать "правильно структурируйте предметную область" (т.е. это значит почти ничего не сказать). В РМ нет средств для работы с доменами, что делает ее одноногим подходом, да и единственная нога еще и хромает. Вот людям и приходится выдумывать как сплясать лязгинку на одной хромой ноге. Конечно, во многом спасают инженеры, постоянно прикручивая к РСУБД новые механизмы. Но их количество настолько возросло, что намного превышает родные с буквой Р, но все равно танцевать тяжело. В общем, моделирование доменов это не менее важная часть, чем моделирование отношений, но если для отношений еще что-то есть, то для доменов пока маловато будет.
20 сен 07, 19:39    [4696428]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
лач
Guest
ПКН
Зл0й
Экая редкостная ересь. Sybase IQ что, не реляционная СУБД? Она как раз и есть column-store а не row-store. "Уж сколько раз твердили миру" что логическая модель данных (т.е. реляционная) и модель физического их хранения (т.е. куча, сбалансированное Б* дерево, или column-store) есть вещи совсем разные.
тогда любую бд можно назвать реляционной

Все зависит от уровня, который используется для моделирования и доступа к данным. Поэтому действительно любую СУБД можно сделать реляционной, если навесить соответствующий API или интерпретаторо запросов. И наоборот, можно взять любую РСУБД, навесить на нее сервер приложений и сделать ее ОО. В этом случае та самая РСУБД будет играть роль просто физического хранилища (физический уровень организации данных). Ну или если в РСУБД хранится XML, то же самое получаем. Реляционщики обычно этого не понимают, и считают, что РСУБД находится на вершине всего мира :)
20 сен 07, 19:45    [4696437]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
а объектщики сами себе боятся признаться что все их обращения к объектам транслируются в нормальный SQL
20 сен 07, 20:41    [4696572]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
shuklin
Member

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

Наглая ложь )))) В Cerebrum нету SQL. У меня "язык" запросов является объектной моделью.
И таблицы в Cerebrum вовсе не отношения а коллекции узлов графа.
20 сен 07, 21:20    [4696652]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
ПКН
Зл0й
Экая редкостная ересь. Sybase IQ что, не реляционная СУБД? Она как раз и есть column-store а не row-store. "Уж сколько раз твердили миру" что логическая модель данных (т.е. реляционная) и модель физического их хранения (т.е. куча, сбалансированное Б* дерево, или column-store) есть вещи совсем разные.
тогда любую бд можно назвать реляционной

Очередная бредятина. Реляционной можно назвать только СУБД поддерживающую реляционную логическую модель данных. Например IMS, Cache, IDMS, Mumps, Berkeley DB и многие другие СУБД реляционными не являются. А вот MySql является, даже если в качестве storage engine используется тот же самый Berkeley DB.
20 сен 07, 22:31    [4696826]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
лач
Поэтому действительно любую СУБД можно сделать реляционной, если навесить соответствующий API или интерпретаторо запросов.

Можно. Но работать такая конструкция будет через пень-колоду. К IDMS и всевозможным MUMPS-оидным системам прикручивали реляционную морду и не раз. Ни одна такая система "с реляционной мордой на нереляционных кишках" так и не достигла уровня работоспособности (стабильности и производительности) при котором ее можно было бы использовать в production environment. Поэтому они и вымерли, как динозавры.

Если бы вы внимательно почитали Readings in Database systems и другие классические книжки (Джима Грея например) то такие идеи вам в голову бы больше не приходили бы. Просто потому, что вы бы знали что эти идеи мы "уже проходили" в 70х годах прошлого века. И результат давно известен.
20 сен 07, 22:42    [4696850]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
MX -- ALEX
Guest
Зл0й
лач
Поэтому действительно любую СУБД можно сделать реляционной, если навесить соответствующий API или интерпретаторо запросов.

Можно. Но работать такая конструкция будет через пень-колоду. К IDMS и всевозможным MUMPS-оидным системам прикручивали реляционную морду и не раз. Ни одна такая система "с реляционной мордой на нереляционных кишках" так и не достигла уровня работоспособности (стабильности и производительности) при котором ее можно было бы использовать в production environment. Поэтому они и вымерли, как динозавры.

Если бы вы внимательно почитали Readings in Database systems и другие классические книжки (Джима Грея например) то такие идеи вам в голову бы больше не приходили бы. Просто потому, что вы бы знали что эти идеи мы "уже проходили" в 70х годах прошлого века. И результат давно известен.


У mumps-оидной CACHE, например,
вполне адекватная СВОЯ НЕРЕЛЯЦИОННАЯ МОРДА,
ей чужие ни к лицу.

Прикрученный SQL нужен ей чаще всего чтобы выкачать данные из
соседних - реляционных - серверов, быстро их обработать и вернуть обратно результат,
причем SQL - динозавр за это время даже не успевает сообразить, что с ним
произошло.
20 сен 07, 23:26    [4696919]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
вероятно не "SQL - динозавр" а те тулзы которые в каше заниматся маппированием
20 сен 07, 23:39    [4696938]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
ПКН
Guest
Зл0й
лач
Поэтому действительно любую СУБД можно сделать реляционной, если навесить соответствующий API или интерпретаторо запросов.

Можно. Но работать такая конструкция будет через пень-колоду.
Быстренько и легко выведите таблицу из колнчатой СУБД... Поэтому и не надо говорить что колончатые субд - реляционные. Да и авторы их таковыми не считают. Их главное преимущество гибкость структуры. Уже это противоречит реляционным догмам.
21 сен 07, 01:20    [4697059]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 [9] 10 11 12 13 .. 51   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить