Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 19 20 21 22 23 [24] 25 26 27 28 .. 51   вперед  Ctrl
 Re: Закат RDBMS?  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
мод
мод
Т.е. те которые работают не только с таблицами или вообще обходятся без таблиц, уже не СУБД ? :-)
Примеры плиз (мумпс что-ли ?)

Да мля хоть MS SQL
http://technet.microsoft.com/ru-ru/library/ms189051.aspx
12 ноя 07, 14:04    [4904460]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
мод
Guest
Локшин Марк
Да мля хоть MS SQL
Что это было ?
12 ноя 07, 15:07    [4905009]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
мод
Что это было ?

Это к тому, что утверждалось несколько постов назад
мод
Все СУБД хранят данные в таблицах

Потому, как по-другому объяснить что это не так, я уже и не знаю. Если уж сайту производителя не верить. Ну бывают, конечно, тяжелые случаи...
12 ноя 07, 16:22    [4905602]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
мод
Guest
Локшин Марк
Ну бывают, конечно, тяжелые случаи...

Тяжелее не бывает:
автор
Таблицы и индексы хранятся в виде коллекции страниц размером 8 КБ

Вы хоть физическую орг. от логической отличаете (говорил же - думать надо)
12 ноя 07, 16:41    [4905787]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
мод
Вы хоть физическую орг. от логической отличаете (говорил же - думать надо)

Вот вот, думать надо
мод
Все СУБД хранят данные в таблицах

Это чьё?
12 ноя 07, 16:47    [4905836]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
мод
Guest
Локшин Марк
Это чьё?

Жду новых примеров (MS SQL не пойдет)
12 ноя 07, 17:12    [4906029]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
мод
Жду новых примеров (MS SQL не пойдет)

Оригинально, значит хранится в виде коллекции страниц, которая является B-деревом или кучей и уже не подходит.
12 ноя 07, 17:21    [4906100]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
мод
Бред
Какие еще три МД?

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


Продолжается выдергивание отдельных предложений, и, банальная ложь (поскольку времени прошло немало, непониманием я это уже не могу назвать, банальная преднамеренная ложь).
13 ноя 07, 22:13    [4912151]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
мод
Бред
За основу РМД не взята - это же очевидно: не поддерживается фундаментальная, по существу единственная, концепция РМД - отношение.

Повторяю еще раз - все СУБД работают только с таблицами. Выяснение отличия таблицы от отношения оставляю для наиболее любознательных.


Неправда. Только СУБД с пока не известным названием в некотором смысле работают с "таблицами". Какую модель данных они используют Вы не знаете. Ни в одной известной мне модели данных нет понятия "таблица".
13 ноя 07, 22:18    [4912159]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
ModelR
Бред
Вы допустили попутно совсем уж некорректный поступок, приписав мне чужие слова:
Истинно виноват, извините. Пост 4896676 содержащий "(2) идентифицирующие (уникальные) свойств" действительно подписан начало Что касается клонов, то мне не очень интересно - клоны или нет, что конечно не оправдывает мою невнимательность при цитировании.

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


Абсолютно верно! Вы только сказали: "Какая разница, как обозвать не ключевую часть данных?"
Утверждение "В РМД кортеж - это, пользуясь вашими понятиями, "ключевая часть данных", по определению (так как в отношении не может быть одинаковых кортежей)." принадлежит, конечно же, мне (иначе я сделал бы ссылку), и в нем используется Ваш, весьма понятный, термин.
13 ноя 07, 22:24    [4912176]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
okdoky
pavelvp
Хотя и связь тоже может не сработать, если на "Маша" откликнется Нина :)

Вот именно. К моменту, когда Вы позвали Машу, процесс идентификации был уже завершен - Вы уже решили - Вам нужна именно Маша. Происходящее дальше к идентификации отношения не имеет. Это в том случае, если имя "Маша" является идентификатором.
По вашей логике, так как "Маша" идентификатор, идентификация сводится к идентификации идентификатора "Маша". Вы даже не пытаетесь высказать свое понимание идентификации, как это делает Бред или ModelR. Соберитесь с мыслями. Как вы будете идентифицировать саму Машу, если знаете только, что у нее есть имя? И что будет являться тогда идентификатором самой Маши? Вы не далеко ушли от Бреда, который заявляет, что описывающие признаки не могут являться идентификатором.

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


Хотел бы уточнить: не "не могут являться", а "не являются".
13 ноя 07, 22:27    [4912184]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
ModelR
MX -- ALEX
okdoky
то есть идентификатором мож быть все что угодно -
лишь бы идентифицировало более-менее надежно

а что - пожалуй верно !

Все что угодно по физической так сказать природе. Однако есть (хотя и несколько схоластический) вопрос о различении ключей и идентификаторов, и о существовании идентификаторов отдельно от объектов.
MX -- ALEX


vadiminfo
а тоже верно !
какая разница, какая там МД
если все крутится тип топ

100%


Не согласен, что схоластический. Ведь в результате все крутится не "тип топ": ни в "Р"БД, лишенных идентификации, навигации и семантики, когда метаданные хранятся в приложении, и без программистов нельзя получить никаких данных; ни, например, в приложениях MUMPS, когда "Маша" и "Нина" делают "идентификаторами".
13 ноя 07, 22:32    [4912193]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
мод
Guest
Бред
банальная преднамеренная ложь

А можно про "преднамеренная" подробнее ?
зы все я что я пишу, я пишу не для вас, а для юных пиоэнеров, которые еще не очень понимают, кого слушать а кого нет.
14 ноя 07, 09:48    [4912899]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
мод
Guest
Бред
Только СУБД с пока не известным названием ...Ни в одной известной мне модели данных нет понятия "таблица".

Т.е. никаких СУБД вы не знаете, МД то же. Вашим ликбезом вы должны заняться самостоятельно.
14 ноя 07, 09:52    [4912917]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
мод
Бред
банальная преднамеренная ложь

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


Куда уж подробнее: преднамеренная (и я объяснил почему именно она преднамеренная).
14 ноя 07, 20:21    [4917883]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
мод
Бред
Только СУБД с пока не известным названием ...Ни в одной известной мне модели данных нет понятия "таблица".

Т.е. никаких СУБД вы не знаете, МД то же. Вашим ликбезом вы должны заняться самостоятельно.


Спасибо. Пошел заниматься своим ликбезом.
14 ноя 07, 20:22    [4917884]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Бред

ModelR
Однако есть (хотя и несколько схоластический) вопрос о различении ключей и идентификаторов, и о существовании идентификаторов отдельно от объектов.


Не согласен, что схоластический.
Схоластический в том смысле, что часть/не часть целиком зависит от текущей точки зрения.
Типа во всяком сущем обнаруживаются части, и всякое сущее - суть часть по крайней мере одного чего-то большего.

Неверно, что паспорт - часть объекта "Человек", но верно, что паспорт - часть вполне по жизни реального объекта "Человек и паспорт при нем".
15 ноя 07, 16:47    [4922000]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
okdoky
Member

Откуда:
Сообщений: 349
mir
okdoky
mir
okdoky

SQL
select A from R1, R2 where R1.B = R2.B and R2.C = c1
Zigzag
= A(B(C:c1))
Вообще неясно, какая связь между первым и вторым текстами, кроме одинаковых букв A, B, C. В первом случае эти буквы -- имен атрибутов отношений R1, R2. Во втором -- неизвестно что.
В первом и во втором случае A,B,C это имена колонок. Как Вам еще проще объяснить, не знаю.
Имена колонок чего, простите? А если в базе 100 отношений, в который есть такие атрибуты? Откуда в вашем выражении СУБД узнает, к каким отношениям относятся эти имена? Мне правда интересно.
"А если в базе 100 отношений…". Это Вы о чем, уважаемый mir, о 100 таблицах? Где-то Вы согласились, что даже один кортеж представляет собой отношение. Все Ваши проблемы в том, что Вы как-то незаметно для самого себя отношение сводите к таблице. Конечно, в Вашем понимании это особая таблица, отображающая нормализованное отношение. Возможно когда-нибудь Вы поймете, что даже 100 таблиц можно представить одной общей таблицей, отображающей одно (денормализованное) отношение. Конечно представить где-то внутри компьютера, не на бумаге. Возможно тогда Вам легче будет понимать и Зигзаг-запросы и особенности колончатых СУБД. Все Ваши вопросы окажутся совершенно лишними и увы не так интересными, как сейчас.
17 ноя 07, 21:22    [4929840]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
vadiminfo
Member

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

Где-то внутри компьютера? Неужели прямо на системной плате "общую таблицу" кто-то накарябает гвоздем? Колончатые СУБД? Зигзаг? Т.е. када будет карябать из-за неловкости нарисуются всякие зигзаги? Ить его - компьютер тот могут и не взять в ремонт после этого. Может разумнее бумагу портить?
Сейчас это интересно?
Но хоть есть надежда, что в будующем эти вопросы станут лишними и тем более не интенресными.
Может хоть тада что поинтересней появится.
18 ноя 07, 23:20    [4931318]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
НПК
Guest
okdoky
даже 100 таблиц можно представить одной общей таблицей, отображающей одно (денормализованное) отношение.
Почему Зигзаг и колончатые СУБД работают быстрее чем РСУБД? Это связано с денормализацией? Но тогда получается большая избыточность?

Как денормализуется такое отношение?
ОТДЕЛ   ДИРЕКТОР  ФИЛИАЛ
АСУ     Петров    ИТ
ППО     Светлов   ИТ

ФИЛИАЛ  ДИРЕКТОР
ИТ      Валенков
19 ноя 07, 05:17    [4931510]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
okdoky
Member

Откуда:
Сообщений: 349
НПК
Почему Зигзаг и колончатые СУБД работают быстрее чем РСУБД? Это связано с денормализацией? Но тогда получается большая избыточность?

Как денормализуется такое отношение?
ОТДЕЛ   ДИРЕКТОР  ФИЛИАЛ
АСУ     Петров    ИТ
ППО     Светлов   ИТ

ФИЛИАЛ  ДИРЕКТОР
ИТ      Валенков

Это уже поинтереснее вопросы ;). Я бы задал еще интересный вопрос, что все-таки является настоящей РСУБД, табличная или колончатая? Проблема табличных СУБД (ТСУБД), типа Оракэл и пр.: чтобы отразить реальное отношение приходится разбивать данные (это отношение) на множество нормализованных таблиц. При выполнении запроса с JOIN Т-система тратит время на дополнительные переходы от таблицы к таблице, от одних полей к тем же самым полям но в другой таблице.

Денормализованное отношение в памяти К-систем (Зигзаг) хранится не в том виде, в каком мы видим на бумаге. Зависимость между колонками в отношении можно представить так
ОТДЕЛ -> ДИРЕКТОР, ФИЛИАЛ
ФИЛИАЛ -> ДИРЕКТОР
То есть непосредственно от ФИЛИАЛА можно перейти только к ДИРЕКТОРУ Валенков. Для выполнения запросов существует и обратная связь от ДИРЕКТОРА к ОТДЕЛУ и ФИЛИАЛУ. Причем понятно, что от ДИРЕКТОРА Валенков мы не сможем напрямую перейти к ОТДЕЛУ, только к ФИЛИАЛУ ИТ. Я бы условно представил такое отношение на бумаге так

ОТДЕЛ  ФИЛИАЛ  ДИРЕКТОР
АСУ    ИТ      Петров
ППО    ИТ      Светлов
       ИТ      Валенков
Опять же эта таблица и она не отражает зависимости между значениями колонок Внутри в СУБД она представляется иначе. Там внутри нет повторений поля ИТ и пустых полей нет. Все основано на индексации и ссылках от одних значений колонок к другим. Колонка ФИЛИАЛ реально имеет вид общего домена
ФИЛИАЛ
ИТ

Имена доменов и атрибутов как мы выяснили ранее, оказывается могут совпадать.
(эта инф не для mir и vadiminfo).
19 ноя 07, 21:30    [4936328]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
okdoky

(эта инф не для mir и vadiminfo).

Тем более что это собственно и не инф никакая.
Особенно если учесть, что полно парней не умеют нормализовать, и потому им ничего нормализовать не приходится, чтобы "отразить реальное отношение". Впрочем, те кто это умеют, делают это, скорее всего, ничего не зная про деление отношений на реальные и не реальные. В теории РБД вроде про "реальность" отношений ничего до сих пор не было (например у Мейра).
Пердставление зависмостей не удачное. В рамках РМД Ф зависимости ФИЛИАЛ -> ДИРЕКТОР вообще нет (первое отношение такое нарушает).
От ФИЛИАЛА можно "перейти" и к ДИРЕКТОРУ Петрову, например.
Ну а про Зигзаг вообще читать не стоит: достаточно прочитанного ранее.
Но я благодарен за заботу, в виде попытки оградить меня от такой якобы инф.
20 ноя 07, 00:07    [4936602]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
okdoky
Member

Откуда:
Сообщений: 349
okdoky
Денормализованное отношение в памяти К-систем (Зигзаг) хранится не в том виде, в каком мы видим на бумаге. Зависимость между колонками в отношении можно представить так
ОТДЕЛ -> ДИРЕКТОР, ФИЛИАЛ
ФИЛИАЛ -> ДИРЕКТОР
То есть непосредственно от ФИЛИАЛА можно перейти только к ДИРЕКТОРУ Валенков. Для выполнения запросов существует и обратная связь от ДИРЕКТОРА к ОТДЕЛУ и ФИЛИАЛУ. Причем понятно, что от ДИРЕКТОРА Валенков мы не сможем напрямую перейти к ОТДЕЛУ, только к ФИЛИАЛУ ИТ.

vadiminfo
Пердставление зависмостей не удачное. В рамках РМД Ф зависимости ФИЛИАЛ -> ДИРЕКТОР вообще нет (первое отношение такое нарушает).
От ФИЛИАЛА можно "перейти" и к ДИРЕКТОРУ Петрову.
Может и хорошо, что пример неудачный. Придется пояснить. Зависисимость между колонками ФИЛИАЛ -> ДИРЕКТОР только позволяет устанавливать связи между их значениями, но в соответствующей БД задана одна связь между значениями ФИЛИАЛ:ИТ -> ДИРЕКТОР:ВАЛЕНКОВ. Это можно увидеть в нормализованной таблице
ФИЛИАЛ  ДИРЕКТОР
ИТ      Валенков
При выводе содержимого колончатой базы, на бумагу выводятся именно нормализованные таблицы. Они нагляднее отражают связи. Знать имена таких таблиц системе необязательно, хотя задать их на всякий случай можно. Они могут храниться внутри или даже генерироваться по имени ключевого столбца. Надеюсь теперь все понятно.
20 ноя 07, 02:32    [4936749]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
okdoky
Может и хорошо, что пример неудачный. Придется пояснить. Зависисимость между колонками ФИЛИАЛ -> ДИРЕКТОР только позволяет устанавливать связи между их значениями, но в соответствующей БД задана одна связь между значениями ФИЛИАЛ:ИТ -> ДИРЕКТОР:ВАЛЕНКОВ. Это можно увидеть в нормализованной таблице
ФИЛИАЛ  ДИРЕКТОР
ИТ      Валенков

Проблема в том что одноименные атрибуты (ФИЛИАЛ ДИРЕКТОР) есть и в первом отношении.
Если ДИРЕКТОР в первом отношении и ДИРЕКТОР во втором это разные атрибуты с одинаковыми именем, то про это БД ничего не "знает". Тем более теория РБД. Поэтому формально Ф зависимостей нет. Если же их назвать по разному:
в первом отношении ДИРЕКТОР_ОТДЕЛЕНИЯ, а во втором ДИРЕКТОР_ФИЛИАЛА, то тогда "ОБЩЕЕ ОТНОШЕНИЕ" содержит типа четыре колонки, а не три, по всем законам жанра.
Если же в примере это разные атрибуты с одинаковыми именами, то и Вы должны были получить как-то отношение с четырьмя (двумя колонками ДИРЕКТОР), а не тремя, потому что интерпритация в РМД не должна зависеть от значений, а только от наименования отношений и атрибутов (если речь не об отчатах, а об отношекниях БД).
okdoky

При выводе содержимого колончатой базы, на бумагу выводятся именно нормализованные таблицы. Они нагляднее отражают связи. Знать имена таких таблиц системе необязательно, хотя задать их на всякий случай можно. Они могут храниться внутри или даже генерироваться по имени ключевого столбца. Надеюсь теперь все понятно.

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

ПС
А если бы все было так просто и рационально (без проблем) как Вы пытаетенсь представить, то до этого уж как-нить давно додумались более продвинутые производители СУБД, чем Зигзаг.
Сравните хотя бы теорию РБД и Ваши мыстли по сложности, и поймете что там все прокапали реальные профи. Они все простенькие мысли наверняка проверили.
20 ноя 07, 09:12    [4936981]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
НПК
Guest
okdoky
ОТДЕЛ  ФИЛИАЛ  ДИРЕКТОР
АСУ    ИТ      Петров
ППО    ИТ      Светлов
       ИТ      Валенков
Опять же эта таблица и она не отражает зависимости между значениями колонок
Ага, то есть это даже не соединение JOIN, а в своем роде объединение отношений. Тогда сильной избыточности действительно нет, только пустые поля. Возможно это и денормализованное отношение, но не по той РМД схеме, с использованием отдельных атрибутов для разных доменов, как заметил vadiminfo. То есть желательно использовать отдельные атрибуты ДИРЕКТОР_ОТДЕЛЕНИЯ, ДИРЕКТОР_ФИЛИАЛА.
20 ноя 07, 10:27    [4937320]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 19 20 21 22 23 [24] 25 26 27 28 .. 51   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить