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

Откуда:
Сообщений: 9365
okdoky
Денормализованное отношение в памяти К-систем (Зигзаг) хранится не в том виде, в каком мы видим на бумаге.


А какие при этом используются чернила ? Это очень важно, поскольку фиолетовые чернила быстро выцветают на солнце, а черные нет. Или все-таки используется грифель ???
20 ноя 07, 11:04    [4937580]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
okdoky
Member

Откуда:
Сообщений: 349
НПК
okdoky
ОТДЕЛ  ФИЛИАЛ  ДИРЕКТОР
АСУ    ИТ      Петров
ППО    ИТ      Светлов
       ИТ      Валенков
Опять же эта таблица и она не отражает зависимости между значениями колонок
Ага, то есть это даже не соединение JOIN, а в своем роде объединение отношений. Тогда сильной избыточности действительно нет, только пустые поля. Возможно это и денормализованное отношение, но не по той РМД схеме, с использованием отдельных атрибутов для разных доменов, как заметил vadiminfo. То есть желательно использовать отдельные атрибуты ДИРЕКТОР_ОТДЕЛЕНИЯ, ДИРЕКТОР_ФИЛИАЛА.
ОК, использовать отдельные имена атрибутов конечно можно, если это действительно разные домены. Но даже эта таблица позволяет перейти к "Директору филиала отдела АСУ". Система не будет пробегать по всем записям в таблице. От отдела АСУ перейдет по внутренней ссылке к филиалу ИТ, и от филиала ИТ к директору Валенков. Если договорится, что все записи в объединенной таблице имеют зависимость ПЕРВОЕ ЗНАЧЕНИЕ -> ОСТАЛЬНЫЕ ЗНАЧЕНИЯ, эту зависимость можно увидеть в объединенной таблице

В соединенной таблице такая зависимость не видна. Не понятно с чем связан фил_директор Валенков то ли с отделом, то ли с отд_директором, а может и с филиалом.
ОТДЕЛ  ОТД_ДИРЕКТОР ФИЛИАЛ  ФИЛ_ДИРЕКТОР
АСУ    Петров       ИТ      Валенков
ППО    Светлов      ИТ      Валенков
20 ноя 07, 19:28    [4941853]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
okdoky
Member

Откуда:
Сообщений: 349
Получается к колоночным СУБД больше подходит операция объединения, а к строчным, операция соединения. Для строчных СУБД обязательно нужна нормализация для отражения зависимостей...
20 ноя 07, 19:35    [4941875]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
okdoky
Если договорится, что все записи в объединенной таблице имеют зависимость ПЕРВОЕ ЗНАЧЕНИЕ -> ОСТАЛЬНЫЕ ЗНАЧЕНИЯ, эту зависимость можно увидеть в объединенной таблице

Лучше не догововариваться, а то так и заговориться не долго. Ссылки и "первые значения" - это из жизни иерахических СУБД. Это первое поколение СУБД. Если продолжать в том же духе то и до файловых систем можно докатиться

okdoky

В соединенной таблице такая зависимость не видна. Не понятно с чем связан фил_директор Валенков то ли с отделом, то ли с отд_директором, а может и с филиалом.
ОТДЕЛ  ОТД_ДИРЕКТОР ФИЛИАЛ  ФИЛ_ДИРЕКТОР
АСУ    Петров       ИТ      Валенков
ППО    Светлов      ИТ      Валенков

В соединенной таблице на лицо Ф зависимости, и все сразу ясно:
Выленков директор филиала, в которм есть два отдела с двумя директорами оных.
Так что тут то как раз все про этого Валенкова понятно. Просто на лицо избыток и аномалии удавления (если удалить все отделы то и Валенкова придется удалить) и ввода.
Потому луче иметь два отношения, которые и устранят эти траблы.
20 ноя 07, 21:13    [4942050]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
okdoky
НПК
Почему Зигзаг и колончатые СУБД работают быстрее чем РСУБД? Это связано с денормализацией? Но тогда получается большая избыточность?

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

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

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

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

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

Имена доменов и атрибутов как мы выяснили ранее, оказывается могут совпадать.
(эта инф не для mir и vadiminfo).


Уважаемый okdoky. Относительно этой простой схемы
Филиал{Обозначение,Фамилия директора}
Отдел{Обозначение,Фамилия директора}
Филиал--состоит из/входит в-->Отдел
(в которой НПК допустил несколько ошибок: неправильно именовал "поля", не отразил семантику связи - а может Отдел "находится на территории" Филиала)
меня интересует вот какой вопрос. Какую именно схему БД Вы создадите? Не могли бы создать, а именно реально создадите для данного приложения. vadiminfo, например, схему, приведенную НПК, точно не создаст. Если можно, приведите конкретные команды создания схемы БД в Зигзаг, чтобф стало понятно как именно идентифицируются элементы схемы.
Спасибо.
21 ноя 07, 11:54    [4943889]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
vadiminfo
okdoky
Если договорится, что все записи в объединенной таблице имеют зависимость ПЕРВОЕ ЗНАЧЕНИЕ -> ОСТАЛЬНЫЕ ЗНАЧЕНИЯ, эту зависимость можно увидеть в объединенной таблице

Лучше не догововариваться, а то так и заговориться не долго. Ссылки и "первые значения" - это из жизни иерахических СУБД. Это первое поколение СУБД. Если продолжать в том же духе то и до файловых систем можно докатиться

okdoky

В соединенной таблице такая зависимость не видна. Не понятно с чем связан фил_директор Валенков то ли с отделом, то ли с отд_директором, а может и с филиалом.
ОТДЕЛ  ОТД_ДИРЕКТОР ФИЛИАЛ  ФИЛ_ДИРЕКТОР
АСУ    Петров       ИТ      Валенков
ППО    Светлов      ИТ      Валенков

В соединенной таблице на лицо Ф зависимости, и все сразу ясно:
Выленков директор филиала, в которм есть два отдела с двумя директорами оных.
Так что тут то как раз все про этого Валенкова понятно. Просто на лицо избыток и аномалии удавления (если удалить все отделы то и Валенкова придется удалить) и ввода.
Потому луче иметь два отношения, которые и устранят эти траблы.


Траблы устранятся. Но при этом в "соединенной таблице", полученной в результате алгебраической операции, ничего не ясно. Приходится интепретировать, анализируя данные. Веселая задача для пользователя: применять к данным "Ф зависимости". (okdoky имел в виду, что на уровне схемы ничего не ясно.)
21 ноя 07, 12:00    [4943941]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
okdoky
Member

Откуда:
Сообщений: 349
Бред
Уважаемый okdoky. Относительно этой простой схемы
Филиал{Обозначение,Фамилия директора}
Отдел{Обозначение,Фамилия директора}
Филиал--состоит из/входит в-->Отдел
(в которой НПК допустил несколько ошибок: неправильно именовал "поля", не отразил семантику связи - а может Отдел "находится на территории" Филиала)
меня интересует вот какой вопрос. Какую именно схему БД Вы создадите? Не могли бы создать, а именно реально создадите для данного приложения. vadiminfo, например, схему, приведенную НПК, точно не создаст. Если можно, приведите конкретные команды создания схемы БД в Зигзаг, чтобф стало понятно как именно идентифицируются элементы схемы.
Спасибо.
Почему vadiminfo не создаст схему (или зависимость)?

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

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

Если мы удалим только ФИЛИАЛ:ИТ
ФИЛИАЛ:ИТ ~;
Удалится и ДИРЕКТОР:Валенков. Отделы увы останутся. То есть недостатки структуры как у всех сегодняшних РСУБД.

В XML зависимость задается структурой отношения.
<ФИЛИАЛ>
  <ДИРЕКТОР/>
  <ОТДЕЛ>
    <ДИРЕКТОР/>
  </ОТДЕЛ>
</ФИЛИАЛ>
Достаточно удалить элемент филиал, удалятся и все связанные с ним дети (потомки тоже). XML имеет явные преимущества над табличным (строчным или колоночным) представлением.
21 ноя 07, 22:53    [4947605]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
okdoky
Member

Откуда:
Сообщений: 349
okdoky
То есть недостатки структуры как у всех сегодняшних РСУБД.
В Зигзаге отношение A(B(C)) равнозначно отношению {A(B),B(C)}. Возможно это неправильно...
21 ноя 07, 23:02    [4947631]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
okdoky
Получается к колоночным СУБД больше подходит операция объединения, а к строчным, операция соединения. Для строчных СУБД обязательно нужна нормализация для отражения зависимостей...

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

Откуда: Новосибирск
Сообщений: 2402
Блог
О! Тут, оказывается, весело, а я всё проспал!
22 ноя 07, 08:36    [4948066]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
MX -- ALEX
Guest
okdoky

...............
В XML зависимость задается структурой отношения.
<ФИЛИАЛ>
  <ДИРЕКТОР/>
  <ОТДЕЛ>
    <ДИРЕКТОР/>
  </ОТДЕЛ>
</ФИЛИАЛ>
Достаточно удалить элемент филиал, удалятся и все связанные с ним дети (потомки тоже). XML имеет явные преимущества над табличным (строчным или колоночным) представлением.


Абсолютно так же оно представлено и в наших горячо любимых
MUMPS-системах (т. е. в CACHE , MSM , GTM)
только запись компактнее - нет закрывающих тегов

И при удалении филиала тоже автоматом удалятся все его дети-потомки

А вот насчет явного преимущества XML-подобных структур
- не очевидно
об чем и этот долгий разговор
22 ноя 07, 10:22    [4948441]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
ModelR
Member

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

Если мы удалим только ФИЛИАЛ:ИТ
ФИЛИАЛ:ИТ ~;
Удалится и ДИРЕКТОР:Валенков. Отделы увы останутся. То есть недостатки структуры как у всех сегодняшних РСУБД.

ON DELETE CASCADE
22 ноя 07, 12:07    [4949218]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
okdoky
Бред
Уважаемый okdoky. Относительно этой простой схемы
Филиал{Обозначение,Фамилия директора}
Отдел{Обозначение,Фамилия директора}
Филиал--состоит из/входит в-->Отдел
(в которой НПК допустил несколько ошибок: неправильно именовал "поля", не отразил семантику связи - а может Отдел "находится на территории" Филиала)
меня интересует вот какой вопрос. Какую именно схему БД Вы создадите? Не могли бы создать, а именно реально создадите для данного приложения. vadiminfo, например, схему, приведенную НПК, точно не создаст. Если можно, приведите конкретные команды создания схемы БД в Зигзаг, чтобф стало понятно как именно идентифицируются элементы схемы.
Спасибо.
Почему vadiminfo не создаст схему (или зависимость)?

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

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

Если мы удалим только ФИЛИАЛ:ИТ
ФИЛИАЛ:ИТ ~;
Удалится и ДИРЕКТОР:Валенков. Отделы увы останутся. То есть недостатки структуры как у всех сегодняшних РСУБД.

В XML зависимость задается структурой отношения.
<ФИЛИАЛ>
  <ДИРЕКТОР/>
  <ОТДЕЛ>
    <ДИРЕКТОР/>
  </ОТДЕЛ>
</ФИЛИАЛ>
Достаточно удалить элемент филиал, удалятся и все связанные с ним дети (потомки тоже). XML имеет явные преимущества над табличным (строчным или колоночным) представлением.


Если можно, уточните.

1. В Зигзаг нет команд создания элементов БД ("языка определения данных"). Зигзаг интепретирует некий текст, и "разбирается" что это.

2. А "язык манипулирования данными" есть? Как выглядит на языке Зигзаг "запрос"
SELECT *
FROM Филиал
WHERE Фамилия_директора='Валенков'
?

3. Раз Вы "приравняли" Директора (филиала) к Отделам (филиала), то почему Отделы не удалятся?
Получается, если

Филиал(Директор,Отдел)

то Отдел удалится при удалении Филиала.
А если

Филиал(Директор,Отдел(Директор))

то Отдел(ы) не удалятся при удалении Филиала. Странно.

4. Что есть в Вашем примере Филиал? Каким понятиям модели данных Зигзаг соответсвуют:
Филиал
Директор (филиала)
Отдел
Директор (отдела)
?

5. Значение 'ИТ' - это что в Зигзаге? Идентификатор Филиала? Или, все-таки, Обозначение Филиала (а идентификатор "внутри")?

Спасибо.
22 ноя 07, 16:27    [4951379]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
!+!
Guest
db4o 7.0 – высокопроизводительная объектная СУБД с открытым исходным кодом
22 ноя 07, 17:02    [4951688]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
okdoky
Member

Откуда:
Сообщений: 349
vadiminfo
okdoky
Получается к колоночным СУБД больше подходит операция объединения, а к строчным, операция соединения. Для строчных СУБД обязательно нужна нормализация для отражения зависимостей...

Пока вроде ничего не получилось, особенно про "колончатые" и "строчные СУБД".
В РСУБД обе операции (объединения и соединения) вполне подходят…
"строчные СУБД" – это так сейчас Орэкал обзывают. Как же ее опустили несчастную The Oracle DBMS is a “legacy technology”
Essentially, Stonebraker is saying that column-oriented databases are much faster than “traditional” RDBMSs, especially in OLAP and data warehousing applications. He claims that the new design (which is not really that new, since Sybase IQ and others already use it), combined with new compression techniques, result in performance that is 50 times better than row-oriented systems like Oracle.

vadiminfo
А нормализация нужна не для отражения зависимостей, а для оптимизации схемы. Для навязывания зависимостей возможно придется и денормализовать схему.
Ну тогда уж вы точно ничего не отразите. А что, звучит, денормальные РСУБД…
vadiminfo
Все это результаты известны с семидесятых годов. Зачем нам на таком уровне что-то якобы получать, да еще и с такими ошибкИми?
Спите до сих пор (как Павел В.) вот поэтому и ошибкИ.
22 ноя 07, 21:12    [4952751]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
okdoky
Member

Откуда:
Сообщений: 349
Бред
Если можно, уточните.

1. В Зигзаг нет команд создания элементов БД ("языка определения данных"). Зигзаг интепретирует некий текст, и "разбирается" что это.
ДА

2. А "язык манипулирования данными" есть? Как выглядит на языке Зигзаг "запрос"
SELECT *
FROM Филиал
WHERE Фамилия_директора='Валенков'

$x = Филиал(Фамилия директора:'Валенков');
$printTable($x);

3. Раз Вы "приравняли" Директора (филиала) к Отделам (филиала), то почему Отделы не удалятся?
Получается, если
Филиал(Директор,Отдел)
то Отдел удалится при удалении Филиала.
А если
Филиал(Директор,Отдел(Директор))
то Отдел(ы) не удалятся при удалении Филиала. Странно.

Я уже намекал, что на структуру данных в Зигзаге лучше смотреть как на множество колонок (тем кто работает с табличными СУБД). При удалении значения в колонке (поля) Филиал, поле Отдел остается без филиала, но остается связь с полем Директор. Если удалять поля Отдел, значит удалять информацию о нем. Зачем? А вдруг мы захотим эти отделы (со всеми их связями) перевести в другой филиал? Логично, не правда ли? Большой потребности в такой структурной зависимости нет. Если это нужно, мы можем таким Отделам добавить спец. признаки (как в SQL ON DELETE CASCADE) и удалять программно. Например
Отдел (ПРИНАДЛЕЖИТ:Филиал);
При удалении филиала нужно будет запускать программу (или использовать отдельные запросы), которая будет удалять отделы, связанные с ним. Но Зигзаг достаточно выразительный, поэтому у меня не было потребности использовать дополнительные признаки или связи. Например достаточно только
(Филиал:ИТ) ~
Очень просто. Это выражение удаляет все значения (любой колонки) связанные отношением с филиалом ИТ

4. Что есть в Вашем примере Филиал? Каким понятиям модели данных Зигзаг соответсвуют:
Филиал
Директор (филиала)
Отдел
Директор (отдела)
?

Это имена классов. Колонками я называл для mir и vadiminfo, они не понимают по другому.

5. Значение 'ИТ' - это что в Зигзаге? Идентификатор Филиала? Или, все-таки, Обозначение Филиала (а идентификатор "внутри")?
Это идентификатор для
Филиал:ИТ
и имя для
Филиал:#(Имя:ИТ)
В последнем идентификатор задается системой.
22 ноя 07, 22:33    [4952888]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
vadiminfo
Member

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

"строчные СУБД" – это так сейчас Орэкал обзывают. Как же ее опустили несчастную The Oracle DBMS is a “legacy technology”
[quot]Essentially, Stonebraker is saying that column-oriented databases are much faster than “traditional” RDBMSs, especially in OLAP and data warehousing applications. He claims that the new design (which is not really that new, since Sybase IQ and others already use it), combined with new compression techniques, result in performance that is 50 times better than row-oriented systems like Oracle.

Смотря кИто обзывает. Моська тоже лаила на слона. Вы серьезную литературу по БД читаете?

Но тронут Вашим беспокойством об Оракле с Вашими, то заботами о продуктах низшей лиги как Зигзаг, коим помочь врядля моно. Разве в разделе "Прочие СУБД", тем более что не известно СУБД ли оно вообще.

okdoky

Ну тогда уж вы точно ничего не отразите. А что, звучит, денормальные РСУБД…

Думаете от того, чтобы что-то там отражать, нужно не знать зачем нужна нормализация на самом деле, но постоянно упоминать про нее?
Ну а что как звучит (тем более не имеющее рационального содержания), Вам виднее: возможно только звучание поможет продвинуть Зигзаг (судя по всему - это последняя его надежда)

okdoky
Спите до сих пор (как Павел В.) вот поэтому и ошибкИ.

Так как мое бодрстование помогло бы Вам избавиться от желания использовать термины на техническим форуме, звучание которых Вам так нравится, а на изучение содержания оных у Вас, судя по всему, времени нет?
Наоборот, Вам много лучше луче чтобы все спали, по-моему: никто бы и не знал про такие Ваши тексты.
23 ноя 07, 09:49    [4953595]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
okdoky
Бред
Если можно, уточните.

1. В Зигзаг нет команд создания элементов БД ("языка определения данных"). Зигзаг интепретирует некий текст, и "разбирается" что это.
ДА

2. А "язык манипулирования данными" есть? Как выглядит на языке Зигзаг "запрос"
SELECT *
FROM Филиал
WHERE Фамилия_директора='Валенков'

$x = Филиал(Фамилия директора:'Валенков');
$printTable($x);

3. Раз Вы "приравняли" Директора (филиала) к Отделам (филиала), то почему Отделы не удалятся?
Получается, если
Филиал(Директор,Отдел)
то Отдел удалится при удалении Филиала.
А если
Филиал(Директор,Отдел(Директор))
то Отдел(ы) не удалятся при удалении Филиала. Странно.

Я уже намекал, что на структуру данных в Зигзаге лучше смотреть как на множество колонок (тем кто работает с табличными СУБД). При удалении значения в колонке (поля) Филиал, поле Отдел остается без филиала, но остается связь с полем Директор. Если удалять поля Отдел, значит удалять информацию о нем. Зачем? А вдруг мы захотим эти отделы (со всеми их связями) перевести в другой филиал? Логично, не правда ли? Большой потребности в такой структурной зависимости нет. Если это нужно, мы можем таким Отделам добавить спец. признаки (как в SQL ON DELETE CASCADE) и удалять программно. Например
Отдел (ПРИНАДЛЕЖИТ:Филиал);
При удалении филиала нужно будет запускать программу (или использовать отдельные запросы), которая будет удалять отделы, связанные с ним. Но Зигзаг достаточно выразительный, поэтому у меня не было потребности использовать дополнительные признаки или связи. Например достаточно только
(Филиал:ИТ) ~
Очень просто. Это выражение удаляет все значения (любой колонки) связанные отношением с филиалом ИТ

4. Что есть в Вашем примере Филиал? Каким понятиям модели данных Зигзаг соответсвуют:
Филиал
Директор (филиала)
Отдел
Директор (отдела)
?

Это имена классов. Колонками я называл для mir и vadiminfo, они не понимают по другому.

5. Значение 'ИТ' - это что в Зигзаге? Идентификатор Филиала? Или, все-таки, Обозначение Филиала (а идентификатор "внутри")?
Это идентификатор для
Филиал:ИТ
и имя для
Филиал:#(Имя:ИТ)
В последнем идентификатор задается системой.


Понятно. Еще вопросы:

1. "Класс" в Зигзаг имеет одно "свойство" и его "имя" равно имени "класса". Так? (Не стоит, кстати, называть элементы модели не соими именами, типа "колонка").

2. A(B,C(D)) можно "разложить" на
A(B,C)
C(D)

3. Теперь опять про удаление (вернее про понимание структурного аспекта на примере операции удаления).
Пример 1 рассмотрели:
в схеме A(B,C(D))
при удалении A
C(D) остаются.
Теперь Пример2:
в схеме
A(B)
E(B)
при удалении A
что будет с E ?

Спасибо.
23 ноя 07, 18:24    [4957343]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
okdoky
Member

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

"строчные СУБД" – это так сейчас Орэкал обзывают. Как же ее опустили несчастную The Oracle DBMS is a “legacy technology”
[quot]Essentially, Stonebraker is saying that column-oriented databases are much faster than “traditional” RDBMSs, especially in OLAP and data warehousing applications. He claims that the new design (which is not really that new, since Sybase IQ and others already use it), combined with new compression techniques, result in performance that is 50 times better than row-oriented systems like Oracle.

Смотря кИто обзывает. Моська тоже лаила на слона. Вы серьезную литературу по БД читаете?
Ну не знаю, если для вас Стоунбрэйкеры, Дейты и др. критикующие Орэкэл, моськи, то кто тогда слоны? Или слон это Орэкэл, потому что в 50 раз работает медленнее? А серьезная литература, это та, которая не замечает недостатки? Тогда это реклама.
23 ноя 07, 20:05    [4957696]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32896

Привет, okdoky!
Ты пишешь:

okdoky
Дейты и др. критикующие Орэкэл
а можно поподробнее о "Дейт vs Орэкэл" ?

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.4

23 ноя 07, 20:07    [4957697]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
okdoky
Member

Откуда:
Сообщений: 349
vadiminfo
Но тронут Вашим беспокойством об Оракле
Вы же спрашивали, что такое строчные СУБД, вот я вам ответил. Странно, что Вы так тронулись. Значит проснулись. Может это не последняя любовь
23 ноя 07, 20:12    [4957706]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
okdoky
Member

Откуда:
Сообщений: 349
Мимопроходящий

а можно поподробнее о "Дейт vs Орэкэл" ?
mir, ответьте пожалуйста человеку. Вы лучше знаете его работы связанные с реляционное vs табличное
23 ноя 07, 20:17    [4957713]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
okdoky
Member

Откуда:
Сообщений: 349
Бред: Класс в Зигзаге это множество значений иерархически связанных между собой. Пример класса R:[r, R1[r1,…]] . Для директоров можно было использовать класс директор:[(филиал):Валенков, (отдел):[…]].. Мне просто лень показывать его преимущества при использовании иерархических связей и наследования. Интереснее говорить о слабых местах.

Зигзаг оперирует классами, может выполнять операции объединения, пересечения, перехода от одних классов к другим с использованием отношения. В РСУБД это соединенное отношение (то есть "денормальное" для нее). Все эти операции выполняются быстрее, чем в legacy RDBMS (это реклама). Домен в РМД тоже можно рассматривать как класс. Но в РМД, как и в ОМД, классы не являются данными, это всего лишь средство описания данных (типа данных).

На счет удаления для {A(B), C(A,B)}:
Если вы удалите класс A останется отношение {C(B)}
Если вы удалите класс B останется отношение {C(A)}
23 ноя 07, 20:34    [4957740]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
Мимопроходящий

Привет, okdoky!
Ты пишешь:

okdoky
Дейты и др. критикующие Орэкэл
а можно поподробнее о "Дейт vs Орэкэл" ?

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.4


Дейт, критикует Oracle (упоминая "одну из реляционных СУБД"), скорее, "сквозь критику SQL", и в борьбе за чистоту реляционных принципов. По моему и в 8-м издании это осталось. Просто возьмите и почитайте...
23 ноя 07, 21:14    [4957784]     Ответить | Цитировать Сообщить модератору
 Re: Закат RDBMS?  [new]
Бред
Guest
okdoky
vadiminfo
Но тронут Вашим беспокойством об Оракле
Вы же спрашивали, что такое строчные СУБД, вот я вам ответил. Странно, что Вы так тронулись. Значит проснулись. Может это не последняя любовь


Раньше использовался термин записе-ориентированные (ориентированные на обработку записей). И по отношению к моделям данных, и по отношению к СУБД. РМД - записе-ориентированная модель данных, "Р"СУБД - записе-ориентированная СУБД. Это есть и в любимых vadiminfo "толстых книгах". А есть объектно-ориентированные. О них подробно говорили. А вот теперь еще и колонко-ориентированные?
23 ноя 07, 21:23    [4957802]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 20 21 22 23 24 [25] 26 27 28 29 .. 51   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить