Концепции разработки идеальной БД

Здравствуйте. Как-то настораживает, что здесь просто МЕРТВАЯ тишина, но, возможно, это и к лучшему. Я хотел бы обсудить концепции построения моделей и баз данных, сформулировать требования к идеальной БД. По всей цепочке: от ядра до конечного пользователя. Но только концепции - иначе мгновенно утонем.

В первую очередь я хотел бы удостовериться в наличии живых людей вообще на форуме. Особо прошу откликнуться тех, которым данная проблема представляется интересной.

Вместо предисловия

Полистал я несколько рекомендованных ссылок (в том числе три "местных"), а именно:


  • Проектирование баз данных: новые требования, новые подходы
  • Аномалии в реляционных базах данных
  • Кризис баз данных и проблема выбора
  • Базы данных: достижения и перспективы на пороге 21-го столетия
  • Реализация ядра безопасности в информационной системе
  • Словарь метаданных документно-ориентированной информационной системы
  • Управление качеством данных на основе алгоритмов нечеткого поиска

Все, за что глаз зацепился, выкладываю "оптом", без привязки к работе, с комментариями (не всегда совпадающими с авторскими), так что далее идут ИМЕННО МОИ мысли. Впрочем, нет - "местные" я прокомментировал "по месту". Публикации старые, но это не является минусом. Итак, подборка цитат:

  • Двадцать лет практики обучили нас, что иногда нормализованные таблицы это правильно, а иногда нет; базы данных будущего должны предоставлять такой выбор.
  • Большинство организаций сейчас хранят больше данных на десктопах, чем в своих БД. Этими данными на десктопах, часто хорошо структурированными по своей природе, управляет все, что угодно, но не системы управления базами данных.
  • Сегодня объектно-ориентированные базы данных поддерживают один стиль навигации; сетевые СУБД и ISAM - другой. Реляционные базы данных, с другой стороны, обеспечивают запросы и операции на множествах. Высокоуровневые процессоры запросов могут ориентироваться либо на операции со множествами, либо на навигацию указателей или на то и другое. Пользователь может выбирать.
  • Поэлементный навигационный стиль и вычисления, основанные на запросах и ориентированные на множества одинаково нужны. Часто подход, основанный на запросах, - наилучший путь первоначального указания множества записей, в то время как навигационные операции - единственный путь дальнейшей работы с полученными в результате данными в манере достаточно развитой, чтобы удовлетворить потребностям сложных приложений. Чем раньше мы избавимся от необходимости выбора, тем лучше.
  • SQL и надстраиваемые над ним языковые формы более высокого уровня хороши для доступа к традиционным записям данных. Когда речь идет о мультимедийных данных, то здесь часто необходимы совершенно другие формы пользовательских интерфейсов.
  • Одной из самых актуальных задач является создание методики проектирования хороших схем реляционных БД. Вопрос о проектировании "хороших" схем реляционных баз данных изучается в литературе уже свыше двадцати лет. К сожалению, к настоящему моменту так и не появилось общепринятой на практике методики проектирования схем. Проектирование схем БД превращается в искусство. Его результаты полностью зависят от опыта и мастерства проектировщика.
  • Средств для работы с абстрактными типами данных в реляционных СУБД практически нет

Etc., etc., etc. Резюмирую: хватит играть в реляционные погремушки!

Идеальная БД

Идеальная БД: БД, которая не вызывает ни у одного из ее многочисленных пользователей никаких иных чувств, кроме восторга.
Пользователь:

  • Умный Профессионал (все знает, и все умеет).
  • Глупая Кухарка (ни хрена не умеет, ни хрена не соображает).
  • Средний Юзер (любое промежуточное состояние).
  • Любознательный Компьютер (самый активный пользователь).

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

Добиваем РМД

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


  • Сделать многие приложения доступными для непрограммистов в тех случаях, когда ранее программисты были бы необходимы. Благороднейшая цель! Слова самого Кодда: "Важно помнить, что базы данных появились, чтобы приносить пользу конечным пользователям, а не для прикладных программистов, которые сегодня выступают в качестве посредников (middle-men)". И... полностью противоположный заявленной цели результат: именно благодаря Кодду в приложения БД буквально ломанулась целая толпа посредников, благо требования к их квалификации резко снизились.
  • редставления самого Кодда о том, что такое RDM, неоднократно менялись в течение всей жизни. Например, Стоунбрейкер писал, что "можно видеть четыре разных версии" модели. До сих пор это понятие не имеет однозначного толкования. По-видимому, наиболее "классическим" определением следует считать Третий Манифест, поскольку Дейт писал (немного перефразировано): "Мы с Хью Дарвеном хотели, чтобы Манифест отчасти рассматривался бы как определительная формулировка, что такое реляционная модель".
  • Маниакальная борьба Кодда с навигацией (да и сложностью) явно обусловлена знанием о существовании концепций БД от CODASYL, стремлением избавиться от ее недостатков (как и появление 3-го Манифеста обусловлено знанием о существовании SQL, с которым Дейт энд кампани ведут борьбу не на жизнь, а на смерть). Кодд сам отвергал возможность компромисса, любую попытку объединения двух подходов, поскольку в результате "мы получаем ненужную сложность".
  • Авторы Третьего Манифеста прямо говорят, что "сфера их интересов - это абстрактная модель, а не вопросы реализации". Тем не менее, они указывают, что "существует ряд вопросов, на которые пока еще нет удовлетворительных ответов в доступной литературе". Даже при такой, предельно упрощенной постановке вопроса (ведь реализация абстрактных положений может оказаться неэффективной, практически непригодной, или даже вообще невозможной!), Манифест буквально пестрит фразами типа "данный вопрос требует дальнейшего изучения", "эта проблема требует дополнительного изучения", "набросок возможной модели наследования можно получить у авторов" и т.п. Иными словами, авторы открытым текстом признают, что недостаточно разбираются в проблеме - позиция, достойная всяческого уважения, рядом с которой соседствуют наивные, детские попытки "запрещать, и не пущать". Почему "РМ-предписания и запреты не могут быть предметом компромисса"? С какой стати "любые(!) основы для будущего управления данными должны твердо(!) корениться в РМД"? Кто сказал, "направления будущего развития СУБД" должны непременно базироваться на том, что было "впервые представленной миру Коддом в 1969 году"? Мир не обязан все время играть в одни и те же погремушки.

Итак, "новая реляционная алгебра" (по Кузнецову, ее создание относится к высшим достижениям авторов) НЕ ЕСТЬ "оригинальная алгебра Кодда", и отличается от нее "четырьмя основными аспектами". Факт, бесспорно, положительный. Я бы даже сказал - знаковый, символизирующий агонию РМД.

Очередные соображения на тему идеальной БД

  1. Поскольку идеальная БД (СУБД) должна идеально обслуживать любого клиента (при этом информационные потребности пользователей разные, и они изменяются со временем), то все разговоры о "галерах, с цепью на ноге, к другому концу которой приковано ядро" или, другими словами, о "пересечении требований, предъявляемых разными потребителями к базе" есть полнейшая глупость. Идеальная СУБД должна идеально обслуживать ЛЮБОГО пользователя. Это называется "персонификация UI" или, говоря словами для кухарки, "каждому по потребностям". Возражения?
  2. База данных в общем случае является многопользовательской, распределенной, мультимодельной, мультиплатформенной мультибазой данных (совокупность баз данных есть тоже база данных). Каких-либо ограничений на поддерживаемые типы данных, размеры элементов и число связей между ними, на число пользователей и компьютеров распределенной СУБД, платформы и операционные системы, количество баз данных и метаданных в мультибазе не накладывается.
  3. СУБД должна обеспечивать быстрый доступ к данным и высокую релевантность ответов даже при наличии ошибок в запросах и данных, а также эффективную реализацию алгоритмов обработки вновь поступающей (в произвольные моменты времени) информации, верификации БД, коррекции ошибок в данных (в т.ч. изменение структуры БД) и защиты данных. Эффективность алгоритмов не должна ухудшаться с ростом объема данных и сложности их структуры.
  4. СУБД построена по технологии "клиент-сервер". Клиентская часть СУБД не является ее составной частью и должна быть стандартной и аппаратно независимой (броузер). Серверная часть обеспечивает санкционированный доступ к базам данных с целью занесения, удаления, редактирования, поиска, верификации данных, а также модификации схемы БД при необходимости.
  5. Данные в БД могут быть любого типа (числа, строки, графика, музыка, сайты, даты, деньги - любые оцифрованные данные), и образовывать сложные типы данных, представляющих произвольные комбинации данных более простых типов (массивы, списки, деревья, отношения и т.п.).
  6. Данные имеют переменную структуру полей, и каждое поле может быть связано с любыми другими полями БД по разным измерениям, образуя многомерный граф произвольной сложности (мультиграф, псевдограф, циклический граф, бесконечный граф - как угодно), каждый узел которого имеет, в общем случае, переменное количество сязей с другими узлами (ребер), в т.ч. нулевое.

О моделях данных

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

Таким образом, сам того не желая, Дейт дал совершенно блестящее, понятное даже ребенку, определение модели данных: это именно язык! Или, точнее, семество языков: ЯОД - язык определения данных (Data Definition Language, DDL), ЯМД - язык манипуляции данными (Data Manipulation Lanfuage, DML) и... тут же выясняется, что не хватает еще одного языка - для третьего аспекта понятия "модель данных": языка описания правил или ограничений целостности. Можно с достаточной уверенностью предсказать появление таких языков в будущем.

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

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

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

Существуют также группы разнородных элементов, отличающиеся главным образом названием: это struct (языки программирования), class (объектная парадигма), tuple (кортеж, реляционная модель данных), node (узел, теория графов). В самом деле, понятие class отличается от struct лишь возможностью заполнять конкретными значениями поля структуры при ее описании ("в нагрузку", разумеется, получаем конструкторы с десктрукторами). Если мысленно разрешить узлы графа считать не только атомарными элементами, но и структурами, а понятие tuple также сделать полностью эквивалентным понятию struct (т.е. элементом группы может быть группа), мы получим возможность реально сравнивать любые модели данных (а заодно "совершенно бесплатно" получим объектную модель данных на месте реляционной - правда, ценой уничтожения реляционной алгебры).

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

Структурный аспект реляционной модели: данные в базе данных представляют собой набор отношений. Вот оно, главное противоречие: первичный элемент есть таблица, т.е. группа! Если же отношение определить как массив кортежей, а сам кортеж, как совокупность полей, тогда действительно становится возможным реальное сравнение с единичными элементами сетевой модели: узлами и ребрами. Однако мы сразу же увидим и набор жестких ограничений на сложность данных в отношениях: возможность группировки только однородных элементов, возможность представления кортежа лишь одноуровневым деревом и, самое неприятное - невозможность обратиться к элементу по идентификатору, неизбежным следствием чего является концепция "ключа". Ради чего? Ради упрощения формального аппарата алгебры отношений и реляционного исчисления для обработки данных. Причем понятие идентификатора, "жульническим" образом изъятое из модели данных, принципиально не может быть убрано также из РСУБД - ведь даже для тривиального чтения значения ключа нужно получить доступ к кортежу каким-то иным способом.

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

РМД и SQL

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

Сам Кодд пропагандировал трехзначную логику (истина, ложь и NULL), а в 1990 даже четырехзначную, однако из-за высокой сложности(!) в Третьем Манифесте все это запрещено: "больше никаких неопределенных значений и больше никакой многозначной логики"! Тенденция к упрощению, доходящему до неприличия, проходит красной нитью через всю РМД, и это НЕИЗБЕЖНО приводит к ограничениям в сложности самих данных. Иными словами, данные в РБД хронически примитивны: сколько-нибудь сложных конструкций там держать нельзя. И ни сама СУБД, ни проектировщики БД не могут обойти это ограничение. Строго говоря, могут (Когаловский, во всяком случае, об этом говорил), но работать это не будет. Еще точнее - будет, но выполнение сложных запросов растянется на тысячелетия. И никакия "оптимизация" не поможет.

Лично я думаю, что отказ от упорядоченности есть НЕИЗБЕЖНОЕ СЛЕДСТВИЕ "структурного аспекта реляционной модели" (данные в базе данных представляют собой набор отношений, т.е. первичный элемент есть группа). В любом случае, наличие/отсутствие упорядоченности имеет принципиальное значение - это признается обеими сторонами (Дейт тоже категорически против компромиссов). Следовательно, чрезвычайно важно "не ошибиться с направлением" именно на этом "водоразделе".

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

"Переместить прикладное программирование на уровень, на котором множества (и, более конкретно, отношения) трактуются как операнды, а не обрабатываются поэлементно" - замечательная цель: язык, позволяющий работать с множествами, бесспорно, удобен. РМД, однако, предполагает работу ТОЛЬКО с множествами (никаких покортежных операций, единичный кортеж есть просто частный случай множества, категорически запрещается концепция курсора). А в таких "коротких штанишках" становится уже тесно даже SQL - ближайшему родственнику РМД.

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

Есть только один вид доступа к данным, пригодный для реально работоспособной СУБД, и он называется "прямой" (а концепция ключа, между прочим, его явно запрещает - в отличие от SQL). И никакие индексы, никакие костыли не спасут идеологически ублюдочную конструкцию!

Третий Манифест: "РМ-предписания и запреты не могут быть предметом компромисса". Даже несчастный курсор "категорически запрещается" (а уж более примитивной навигации просто не бывает в природе). РМД именно КАТЕГОРИЧЕСКИ запрещает их иметь, ибо концепция ключа мгновенно превращает навигационные операции в рекурсивный SQL-запрос: раз кортежи идентификатора иметь не могут - будь любезен рыскать по ЗНАЧЕНИЯМ, хоть ключом их обзови. И обязательный первичный ключ на реляцию вынь, да положь. И одинаковых кортежей заводить не моги - худо будет. Кодд ненавидел навигацию не меньше, чем Дейт SQL.

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

Вроде как реляционная алгебра (как и реляционное исчисление) обладают какой-то там "полнотой". Наверное, для каких-то там теоретических умозаключений это очень важно. На практике же РМД (как, скажем, и машина Тьюринга) на фиг никому не нужна. Типы данных (string, int, date, boolean, etc.) реляционной теории по барабану. Концептуально, реляционная алгебра оперирует понятием Декартова произведения, которое в реальных РСУБД использовать слишком дорого, поэтому используют различные техники "оптимизации запросов".

Если действительно "РМД лишь предписывает, чтобы результат, например, соединения отношений логически был эквивалентен произведению с последующим ограничением (выборкой)", то какого же черта Дейт страдает, что "Cartesian product and union are both noncommutative"? Чего он с такой ненавистью набрасывается на идентификаторы столбцов и кортежей в SQL? Какое его собачье дело?! РМД не только "никак не предписывает конкретную реализацию этих операций" - она вообще ничего полезного, практически пригодного не предписывает.

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

Клевета Кодда на сетевую модель, попавшая чуть ли не во все учебники, НАПРЯМУЮ связана с тем, что "получение физического доступа к кортежу ЕСТЬ вопрос модели данных". Например: "изменение структуры базы по-прежнему требует значительных усилий и времени, поскольку операции модификации и удаления данных ТРЕБУЮТ ПЕРЕСТАНОВКИ УКАЗАТЕЛЕЙ" - очевидный идиотизм. Или еще один: Those "pointers" needn't be physically represented in storage by actual pointers, but the user can always think of them as actual pointers. (That's the network model!) А вот в РМД - "как это реализуется в конкретной системе - для модели совершенно неважно" - те самые "двойные стандарты", то самое жульничество.

Предположим, мы имеем РБД, состоящую всего из одного отношения. Заведем дополнительный столбец, значениями которого будут порядковые номера кортежей (с единицы). Именами столбцов также установим их порядковые номера (с нуля). Определим нулевой столбец как первичный ключ (или "суррогатный", или "системно-генерируемый", как "весьма настоятельно" рекомендуют авторы Третьего Манифеста). Таким образом, мы можем получать доступ к столбцам и кортежам по их порядковому номеру (как и в SQL), но в строгом соответствии с РМД. Что же изменилось? Мы всего лишь лишились прямого доступа к кортежам и каждому из их полей (раз уж РМ-предписания запрещают упорядочение атрибутов или кортежей), и автоматически перестали "бояться" дубликатов кортежей и неопределенных значений. А где же преимущества того, что наше отношение теперь соответствует требованиям Третьего Манифеста? Их нет! Так в чем же "безнадежность следования извращению РДМ, воплощенному в SQL", как писали Дейт с Дарвеном? С какой стати "чтобы выдержать испытание временем, необходимо недвусмысленно отвергнуть SQL"? Мы можем точно так же ссылаться на кортежи этого отношения из других (или из него самого), можем сразу вычислять физический адрес кортежа по значению внешнего (суррогатного) ключа (и контролировать его при желании по значению нулевого столбца), т.е. внешний ключ реально становится указателем. Таким образом, концепции, воплощенные в SQL, как минимум, не хуже РМД.

Forums: 

Изображение пользователя ipanshin.

Я бы поправил:

Я бы поправил: ТИШИНА. По поводу "МЕРТВАЯ" я сказал бы так

Миражи явлений и событий
Сквозь туман седого Петербурга
Я еще пока не небожитель
Чаще захожу лишь в двери морга...

Точно знаю, что 4 человека на этом форуме живы. А сколько людей требуется, чтобы удостовериться Вам в наличии живых людей вообще на этом форуме?

По Дж.Мартину "Организация баз данных", 1980 года (с годом могу наврать) различают всего три архитектуры построения баз данных:

1. Сетевая
2. Иерархическая
3. Реляционная

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

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

Спасибо!

Уже достаточно! О существовании еще одного я знаю - зарегистрировался здесь после длительной переписки с ним. С меня - "затравочный" пост, но денька два я, видимо, возьму на "раскачку". :)

Изображение пользователя ipanshin.

То есть мы

То есть мы вышли из технической плоскости и работаем в плоскости чувств и эмоций?

В таком случае идеальная база данных у меня вызывает ассоциации тюрьмы времен галер. Цепь+ядро+пользователь - это арестант. То есть у них есть чтото общее. И Умный Профессионал и Глупая Кухарка и Средний Юзер и Любознательный Компьютер встретились на галерах, с цепью на ноге, к другому концу которой приковано ядро. Видимо, одежда у них в полосочку и большое весло в двух руках. Я в восторге.
Обычно я посты стараюсь не редактировать. И второе. Не кажется ли Вам, что таким образом, Вы не хотите изложить свою концепцию идеальной базы, а хотите отточить свое мастерство для будущих словесных баталий?

Все возможно. Ибо зачем собственную свободу ограничивать чужой совестью?

Кстати по поводу кухарки. Вы зря ее обижаете. Она вас кормит и, если поймет свою обиду, то может и яду подсыпать, к примеру.

Ни фига!

Мы НЕ вышли из технической плоскости НО работаем ТАКЖЕ И в плоскости чувств и эмоций!

Ассоциация тюрьмы вряд ли уместна - скорее психбольницы, раз уж ТАКОЕ "не вызывает иных чувств, кроме восторга". И не у ВАС, а у НИХ - см. определение.

Нет, мастерство у меня давно отточено - я хочу обсудить именно концепции, и именно на пальцах. Остальное приложится.

Кухарку я никогда не обижал - я хочу, чтобы И ОНА была в восторге. Ах, да - термин "глупый" можно понимать по-разному. Моя трактовка: кухарка тоже умная, но на кухне. Глупая она здесь, в БД. И ее надо обслужить так, чтобы она не только яду не насыпала, и побаловала фирменным блюдом.

Я в свое время

Я в свое время отписывался по теме баз данных. Будучи старым MSSQL адептом, я потестировал Cassandra.

Работает на JVM, без инсталлера, но все встало у меня под Win без малейших проблем
Управляется консолью (command line), но все очень интуитивно понятно
Так как система новая то у нее почти нет энтропии (груза веков) как у oracle/sql server.

Есть аналог баз и таблиц (они называются column family)
Список колонок не описывается, их можно добавлять какие хочешь. То есть грубо говоря это набор hashTables.
К каждой 'записи' можно обращаться либо по ключу, либо по значению одной из колонок
В этом случае на колонке должен быть индекс. Если его нет, то происходит ошибка, а не full table scan

Главное - база обеспечивает быстрые inserts, и killer feature - масштабируемость.
Собрал N серверов в пачку - они и работают, обмениваются данными.
Вырубился один - никто не заметил.
Нагрузка балансируется.
Сonsistency не гарантируется до конца, то есть если я записал на сервер A, а другой читает с сервера B, то несколько ms я могу получить еще старое значение
В общем для тех целей что она создана (Twitter, Facebook итд) штука полезная

Секундочку!

Я говорил про концепции, а здесь косяком пошла глубокая детализация! Во-первых, здесь уже ТАБЛИЦЫ, которые для меня как красная тряпка, так что, по крайней мере, один юзер не будет испытывать восторга и, следовательно, БД не идеальная (см. определение).

Обращаться "по ключу" - это и есть "по значению". Меня также не устраивает. Не говоря уже про индексы, которые из идеальной БД должны быть вычищены поганой метлой!

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

Сonsistency И НЕ МОЖЕТ быть "гарантирована до конца". И НЕ НУЖНО этого делать.

Там нет ТАБЛИЦ.

Там нет ТАБЛИЦ. Там есть аналог - column family, который чем то таблицу напоминает но ею НЕ является.
Во вторых, идеального нет ничего :)

Пока я вижу такое развитие. Монополия RDBMS разрушена. Они никуда не денутся, банки, транзакции, продажи итд - везде где целостность нужно гарантировать остануться на RDBMS. Блоги, фейсбуки и очень многое другое, для чего нужна масштабируемость а целостность лишь желательна - уже прыгают на новые базы.

Быть может было бы классно иметь совмещение их чтобы был один datasource, а разные сущности могли бы управляться разными engine.
А что вы имеете против индексов? Известно, что все новые базы (и кассандра в том числе) предъявляют еще более жесткие требования к индексированию. Например, если у MS SQL конструкция WHERE MyCol=123 при отсутствии индекса по MyCol приведет к тому, что он будет делать full scan, то cassandra просто откажется искать. И это правильно в ее области - при работе с twitter если запрос уходит в сканирование 100 миллиардов записей, то это ошибка, и такой запрос вообще не должен выполняться - он должен выполняться быстро или никак.

Но есть СТОЛБЦЫ?

Забавно. Впрочем, уже прогресс...

Согласен, идеального нет ничего... кроме обсуждаемой БД! :)

везде где целостность нужно гарантировать остануться на RDBMS.

Ха-ха-ха! Где это Вы умудрились увидеть "целостность" у РБД? А сотни тысяч ошибок на базу не хотите? Я тут покритиковал статью Сергея Тарасова насчет нечеткого поиска...

Быть может было бы классно иметь совмещение их чтобы был один datasource, а разные сущности могли бы управляться разными engine.

А вот здесь ни малейших возражений!

А что вы имеете против индексов?

Часто слышал вопли: "А-А-А-А! Опять индексы навернулись! Это пусть у "MS SQL" голова болит - мы же говорим об ИДЕАЛЬНОЙ базе! ;)

1 Если

1 Если определены Foreign keys (есть и более мягкие методы) то целостность, собака, таки гаранртирована. Нет, вы можете сувать ломики в пилку типа WITH NOCHECK или юзая INSTEAD OF trigger, но вообще она гарантирована. И за этим стоит сотни тысяч долларов.

2 Так как требования, предъявляемые разными потребителями к базе принципиально несовместимы, то их пересечение пусто. И идеальных баз нет.

Понятия "РСУБД" и "Господь" не тождественны.

НИ ХРЕНА там не "гарантировано"! Повторяю: в реальных БД десятки и сотни тысяч ошибок! Хоть за этим стоит сотни тысяч ТРИЛЛИОНОВ долларов!

Так как требования, предъявляемые разными потребителями к базе принципиально несовместимы, то их пересечение пусто. И идеальных баз нет.

А кто здесь говорит о "пересечении"?!

1. Пруфлинк на

1. Пруфлинк на баг что FK не отработал. Не из источника ОБС
2. Пример идеальной программы, машины, еды - любого идеального объекта. Тогда мы продолжим говорить.

А с какой радости он должен отработать?

1. Теоретики так говорят? А криворукие разработчики? А повреждение данных? А... Пример - пожалуйста: тестовая, учебная(!), плюгавенькая по объему БД "Борей" для MS Access - где-то валяется архив, ковыряться лень, так что по памяти: у двух разных компаний (одна чего-то производит, другая чего-то перевозит) один и тот же телефон. Две компании вообще "выпали в осадок" - ни в одной лперации их нет. Какое-то "контактное лицо" родилось позже, чем было принято на работу. Все предприятия Англии импортируют товар со страшной силой, и лишь одна (из Манчестера, кажись) "трудится, как в дизель в заполярье", отбивая английские бабки, и т.д., и т.п.

2. Идеальная БД ВООБРАЖАЕМАЯ. Я хочу сформулировать требования к ней, не озираясь на убогий существующий зоопарк - и только.

1. Понятно. так я

1. Понятно. так я и думал - единственное доказательство - BOLD и пафос.
2. Мой вопрос проигнорирован
Прощайте, господин тролль.

Изображение пользователя ipanshin.

Нет, нет и еще

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

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

Ведь осетрина может быть только первой свежести, она же и последней. Поэтому из первых рук аудитория хочет услышать концепцию идеальной базы. И милейший, если вам говорят, что осетрина второй свежести, то вас обманывают. И не надо озираться на других, они - убоги в том зоопарке, который сами себе построили и сидят в нем. Эти клетки a-la foreign key, эти create index and lock на самом деле тормозят полет мысли и фантазию. А что говорить о чувствах, эмоциях? Наконец счастье. Отбросим шизофрению прошлых и построим новую. Гораздо глобальнее и более весомей. Ну я не знаю каких размеров, но она для идеальной базы данных должна быть идеальных размеров. Какой идеальный размер может быть?
Я знаю 90-60-90. Или золотое сечение Микеланджело. Нет это все не идеально. Я думаю, тут не стоит раздумывать. Надо брать самое лучшее. Не отказывать себе ни в чем. Надо вообще абстрагироваться от прошлого. Забыть, что тебя родила женщина. Ведь идеальную базу должны строить идеальные только. Ведь вы же идеальны?
Фу, устал. Да, через 20 дней солнце приблизится к своему апогею (или перигею (проклятый склероз, его нельзя вылечить только забыть)). Я уже и забыл какого оно цвета. В общем дурацкое время и стихи тоже дурацкие.

Приближаясь к апогею.

Вода, как зеркало. И это не в сезон,
Когда угасли чувства, стихли страсти,
Когда уже не сильно и влюблен,
Освобожден от гордости и власти.

А вместе с тем – ты полон еще сил,
А с этим – уживаешься, как можешь.
Болезнь - одна: звучит как перепил,
Если другую ты стреножишь ...

Ничего я не сформулировал!

Я же говорил про пару деньков на раскачку.

И аудитория, которая только "ждет, когда я здесь и сейчас озвучу эти требования" меня не устраивает. Я хочу ОБСУЖДЕНИЯ! Да, затравочные вещи - с меня.

Консенсус - "бог с ним с этим FK ключем". Позже разовью. Согласен - "не надо озираться на других", я ровно об этом и говорю.

А вот Флуда хотелось бы избежать - я потому и говорил, что желательна модерация ветки. Тема очень флудоемкая, в чем мы уже имели возможность убедиться. Повторяю: я хотел бы поговорить СЕРЬЕЗНО!

P.S. Количество и

P.S.
Количество и тип столбцов там может меняться от записи к записи.
Поэтому она и не реляционная

А что здесь случилось?

По виду - рука модератора прошлась. Стало симпатичнее, но можно узнать подробнее про механизм этого всего?

Изображение пользователя Serguei_Tarassov.

Модератор

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

Спасибо!

Но я вижу это дело немного не так: в корневое попадают отшлифованные формулировки, а по спорным тезисам именно "расплываться". После согласования - перенос в "корень".

Изображение пользователя ipanshin.

Реляционные БД

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

Глава "Идеальная БД" страдает тем, что там отсутствуют определения поднятой темы.

Теперь рассмотрим основной параграф, который проливает некоторый свет на обсуждаемую тему "Очередные соображения на тему идеальной БД":

Возражения есть по первому пункту. Как быть с преступниками?
Пункт два. Можно сказать короче: никаких ограничений.
Пункт 3. QOS = 100%
Пункт 4. Двухзвенка.
Пункт 5 и 6. База объектноориентирована.

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

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

... должны быть отправлены на помойку. :)

Я бы с удовольствием убрал раздел про РБД, но это чуть ли не главный пункт, вызывающий непонимание позиций. Возможно, это нужно выделить в отдельную ветку - здесь же я просто провожу мысль, что идеальная [СУ]БД не может быть реляционной.

Как это "отсутствуют определения поднятой темы"? Я как раз и пытаюсь давать именно определения! Подробнее можно? Теперь по пунктам раздела Идеальная БД:

1. С преступниками НИКАК не быть. Задача СУБД, как и врача, обслужить ЛЮБОГО клиента. Если Вы про вопросы доступа... ну, можно и поговорить, но это (на мой взгляд) вопросы ВТОРОЙ очереди.

2. Сказать-то можно, но информации это никакой не несет. Считаю важным грубо перечислить, КАКИХ ИМЕННО ограничений нет.

3. Не понял совершенно - при чем тут QOS, при чем 100%?

4. Допустим, двухзвенка (хотя это не обязательно). А Вы считаете это недостатком?

5 и 6. При чем здесь "База объектноориентирована"? Абсолютно ни хрена не понял!

Извините, но я не вижу какой-либо новой идеи в этих перечисленных пунктах.

А кто говорит о новых идеях? Я говорю о концепциях идеальной БД.

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

Войну и мир, что ли? Давайте вернемся к ЭТОЙ теме.

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

Что за "аксиома"?!

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

Я, вообще-то, никого еще не ругал. :) И не собираюсь, хотя и не вижу в этом ничего плохого - ругайте МЕНЯ, пожалуйста! Это ЛУЧШИЙ способ отшлифовать формулировки!

Изображение пользователя Serguei_Tarassov.

По идеальной БД

1. Идеальная СУБД должна идеально обслуживать ЛЮБОГО пользователя. Это называется "персонификация UI" или, говоря словами для кухарки, "каждому по потребностям". Возражения?

Это реализовано приложениями БД. Не вижу смысла спускать специализацию на уровень универсальной СУБД. Приложений создано немало для всех перечисленных выше типов пользователей: от консоли администратора, через универсальные "запрос по примеру" (QBE) до специализированных экранов.

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

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

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

Сервер предоставляет API, вот его, а не клиента, и требуется стандартизировать. ODBC, например.

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

По определению, БД - это структурированное хранилище информации. Типы вроде "музыка" неструктурируемы в принципе, т.к. уровень структуризации напрямую зависит от функциональности: от простого BLOB до многоканальной и даже нотной записи. Нормализация в РМ, кстати, тоже, 1НФ зависима от функциональных требований.

6. Данные имеют переменную структуру полей, и каждое поле может быть связано с любыми другими полями БД по разным измерениям, образуя многомерный граф произвольной сложности (мультиграф, псевдограф, циклический граф, бесконечный граф - как угодно), каждый узел которого имеет, в общем случае, переменное количество связей с другими узлами (ребер), в т.ч. нулевое.

Многомерные БД реализованы. Например кубы и MDX, по сравнению с которым SQL кажется простым. Вам не кажется, что сложность языка запросов пропорциональна сложности структур? Как обеспечить полноту языка модели (напомню, SQL реляционно полон)

Именно такое обсуждение я и хотел бы видеть.

Мои комментарии (по той же нумерации пунктов).

1. Приложение БД ТОЖЕ пользователь (для ядра, по крайней мере). Да и вообще, граница между СУБД и приложениями условна: популярные приложения могут перетекать в тело универсальной СУБД, и наоборот. Тем более, что конечному пользователю, как правило, по барабану, кто там с ним "разговаривает". Так что просто имеем УРОВЕНЬ приложений (или там слой - терминология не устоялась).

2-3. Не согласен: это вопросы и модели тоже. Например, тезис "элемент БД может быть БД" - какая же это "реализация"? Это ИДЕОЛОГИЯ! А требование "быстрый доступ к данным" есть просто крест на реляции! И никакие "ограничения существующих моделей" меня не интересуют - мы говорим об ИДЕАЛЬНОЙ БД. Точнее, интересуют, но лишь в том плане, чтобы показать, как они обходятся. :)

4. ХРЕНУШКИ! Для многоуровневой БД буквально КАЖДЫЙ слой является сервером (для вышестоящих) и клиентом (для нижестоящих). Технология "клиент-сервер" работает и внутри СУБД! А, ну да - я ж говорил про браузер... Для ЧЕЛОВЕКА (чистый клиент, не сервер) - это браузер. Ядро (физический уровень) - это чистый сервер. Все остальные уровни - и то, и другое, в одном флаконе. Стандартизовать надо не API, а ЯЗЫКИ взаимодействия.

5. ЕСЛИ "по определению, БД - это структурированное хранилище информации", ТО такое определение устарело. Идеальная БД - это хранилище ЛЮБЫХ (оцифрованных) данных.

6. Я не говорю про многомерные БД - тем более, про несчастные кубы. Я говорю про данные ПРОИЗВОЛЬНОЙ сложности - в том числе, и кубы. Нет, мне не кажется, что сложность языка запросов пропорциональна сложности структур. Я не очень понимаю, что Вы имеете в виду под "полнотой языка модели". Пусть там хоть тыщу раз "SQL реляционно полон" - он же убог и немощен!

Изображение пользователя Serguei_Tarassov.

Приложение БД

1. Приложение БД - это клиент, а не пользователь. Если клиент и сервер исполняются в одном адресном пространстве (например, многие СУБД имеют встраиваемую версию), то технология "клиент-сервер" как таковая отсутствует.

2. "Быстрый доступ к данным" не может ставить крест на РМД. Все операции в реляционной алгебре мгновенны.

3. Внутри СУБД "клиент-сервера" нет, все крутится в одном адресном пространстве, но он может быть между разными модулями СУБД. Язык взаимодействия - часть API.

4. Хранилище - это хранилище. Оно отличается от структурированного тем, что строится не для работы по запросам пользователей, а для хранения с последующей трансформацией данных для интерактивных БД. В datawarehouse никто не запрещает хранить информацию любого типа. Плохая поддержка абстрактных типов данных не есть проблема РМД.

5. SQL реализует все операции реляционной алгебры. Алгебра двумерных множеств вряд ли будет сложнее алгебры множеств произвольного числа измерений.

Приложение - это отдельная большая тема

Скажем, приложение может быть ДАННЫМИ, хранящимися в БД. Но концептуально приложение - это то, что НЕ входит в СУБД и, следовательно, НЕ является предметом обсуждения в этой ветке. Согласны? Теперь по пунктам:

1. Адресное пространство тут ни при чем. Клиент делает ЗАПРОС к серверу на некоем ЯЗЫКЕ общения - сервер ОТВЕЧАЕТ (тоже на некоем языке). Так что концептуально технология "клиент-сервер" присутствует ВСЕГДА! Во всяком случае, в идеальной СУБД. :)

2. А я разве сказал РМД, а не РБД? Ах, я сказал "реляции"... :) А меня не интересует реляционная алгебра - это фикция, пустышка, игрушка для теоретиков. Меня интерсует система, которая удовлетворяет любого пользователя.

3. См. п. 1 - мне добавить нечего.

4. Хранилищу ПО БАРАБАНУ, для чего оно там "строится" - это абсолютно не его собачье дело. Его задача - принять данные, хранить их, обеспечить к ним эффективный доступ, модификацию, удаление. Точка. В идеальной БД никто не запрещает хранить ДАННЫЕ (а не информацию) любого типа, в т.ч. НЕИЗВЕСТНОГО. Проблемы РМД ее также не волнуют. :)

5. SQL пусть реализует, что хочет - кому он вообще нужен? Нет, если кому-то нужен SQL - пусть получит его в полном объеме - БД-то идеальная! Но ведь есть и ДРУГИЕ пользователи! ;) Меня лично ни реляционная алгебра, ни вообще РМД совершенно не интересуют.

Изображение пользователя Serguei_Tarassov.

По определению

1. По определению. "Клиент-сервер" означает два процесса, обменивающихся сообщениями. По вашему определению "клиент-сервер" это даже вызов процедур в программе.

2. Если не РМД, а РБД, значит реализация. Говорить о быстроте доступа к данным в реализации РМД без формализации понятия "быстрый" так же бессмысленно, как и в РМД.

3. См. п.1.

4. СУБД - кроме функций хранения выполняет и другие. Вот эти функции и предъявляют требования к структурированию. Иначе каждая файлопомойка может считаться СУБД.

5. Вы можете привести математику вашей идеальной модели ? Подробности не важны, можно концептуально.

Вот именно!

1. Я говорю ровно то же самое: "Клиент-сервер" означает два процесса, обменивающихся сообщениями. Иными словами, это ЯЗЫК! Да, возможно даже "вызов процедур в программе"!

2. Да, разумеется - кого интересует "мгновенно"? Говорить о быстроте доступа к данным при концепции поиска ПО КЛЮЧУ - насмешка над здравым смыслом.

4. СУБД действительно выполняет много функций. Я перечислил функции ЯДРА. Или физического уровня (слоя). Остальные функции сосредоточены В ДРУГИХ слоях. Некая аналогия - стек протоколов.

5. Давайте вначале модель прорисуем (поверьте, она ОЧЕНЬ сложна), а потом уже займемся математикой.

Изображение пользователя Serguei_Tarassov.

Пока не вижу

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

2. В РМД/РБД нет никакой "концепции поиска по ключу"

3. Функция ядра "поиск по запросу" предъявляет требования к структурированию

4. Пока не увижу нечто осязаемое и обсуждаемое - не поверю, разумеется.

Давайте смотреть внимательнее

1. Два процесса (это понятие тоже требует определения), или "агента", обмениваются информацией (абсолютно наплевать, какое там у них "адресное пространство"). Одного агента(инициирующего обмен) назовем "клиент", второго - "сервер". Они друг друга обязаны понимать, поэтому мы можем говорить о "языке" - хоть "протоколом обмена сообщениями" его назови. СУБД есть набор этих агентов, разнесенных по "слоям" или "уровням" (языков также может быть множество). С одной стороны - конечный пользователь (например, человек), с другой - физический уровень доступа к данным. Общение между ними идет через цепь посредников (агентов разных уровней), которые выступает как клиент в одну сторону, и как сервер в другую. Возражения?
2. Я разве сказал "поиск"? Извиняюсь - я имел в виду "доступ". Такой доступ автоматически предполагает поиск. Консенсус?
3. Это, мягко говоря, спорный вопрос. Она не только не "предъявляет требования" - она ЗНАТЬ НЕ ЗНАЕТ ничего о структуре данных! Напоминаю, я говорю об ИДЕАЛЬНОЙ СУБД. :)
4. Не надо ни во что верить! Концепцию разделения на уровни Вы принимаете - это я видел в Ваших статьях. Вот и давайте обсудим самое простое - физический уровень хранения данных. Напоминаю: данных ЛЮБОЙ структуры, ЛЮБОЙ сложности - лишь бы они были в принципе доступны компьютеру (оцифрованы).

Изображение пользователя Serguei_Tarassov.

Вы путаете

1. Вы путаете декомпозицию системы на уровни/межуровневые интерфейсы/протоколы и их частную реализацию в технологии "клиент-сервер".

2. Доступ - возможность взаимодействия с системой. В РМД/РБД нет никакой "концепции доступа по ключу"

3. Приведите алгоритм поиска подстроки "мама" в бинарном файле.

4. Физический уровень хранения данных - это байты в ОЗУ/ПЗУ/ДЗУ ЭВМ.

Я слишком долго этим занимался, чтобы "путать".

1. Мне нет дела ни до "декомпозиции системы", ни до "частной реализации" - я пытаюсь наладить обсуждение идеологии идеальной СУБД. С двух "крайних" точек: браузера (отдельная ветка), и физ. уровня (здесь). Дай Бог нам пройти хотя бы эти точки (на мой взгляд, самые простые). Тогда и сунемся в "интерфейсы/протоколы".
2. Простите, а ДЛЯ ЧЕГО вообще существуют понятия первичного и внешнего ключа? Читайте Дейта, например: "the information that was represented by a foreign key in the relational design is represented by a link in the network design; links are the network analog of foreign keys (speaking very loosely)".
3. При чем здесь алгоритм поиска подстроки "мама" в бинарном файле, если мы говорим об идеальной СУБД?
4. Совершенно верно! И перечисленный мною выше набор операций. И язык взаимодействия с этим (физическим) уровнем. И отправная точка для обсуждения концепций. Ни малейших возражений!

Изображение пользователя Serguei_Tarassov.

на нет и суда нет

1. Ну, раз нет дела до декомпозиции системы, то "на нет и суда нет"

2. Для поддержки целостности в реализации РМД (о чем вам уже пытался сказать покинувший дискуссию коллега)

3. Приблизим задачу к идеальной БД. Привидите алгоритм поиска всех сущностей типа Unknown или Any, содержащих свойство со значением "мама".

4. Где можно увидеть набор операций?

Разговор у нас стремительно уходит "вправо"

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

1. Ну, раз нет дела до декомпозиции системы, то "на нет и суда нет"
Вот и отлично! Тогда, может, поговорим про концепции идеальной БД?

2. Для поддержки целостности в реализации РМД (о чем вам уже пытался сказать покинувший дискуссию коллега).
Ключи?! Для подержки целостности?! И ТОЛЬКО?! Я привел цитату Дейта. Можете ли Вы (или там "покинувший дискуссию коллега") сказать что-либо более убедительное, чем Ваши голословные заявления? Что до их смысла - на мой взгляд, это просто БРЕД! Как Вы вообще собираетесь "поддерживать целостность", опираясь на какие-то поганые ЗНАЧЕНИЯ?! И, кстати, КАКУЮ "целостность" Вы собрались обеспечивать? Не ссылочную, случайно? ;)

3. Приблизим задачу к идеальной БД. Привидите алгоритм поиска всех сущностей типа Unknown или Any, содержащих свойство со значением "мама".
АЛГОРИТМ?! Во-первых, КТО ищет? Человек? Тогда "алгоритм" состоит в составлении запроса к системе на удобном КОНКРЕТНО ЕМУ языке.

4. Где можно увидеть набор операций?
В этой переписке. Мой пост под шапкой "Приложение - это отдельная большая тема", п. 4.

Изображение пользователя Serguei_Tarassov.

Раз уходит

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

2. Что именно в цитате Дейта говорит о том, что ключи в РМД применяются еще для чего-то кроме ограничений целостности?

3. Запрос на естественном языке "выбрать все сущности со свойством равным "мама". Приведите укрупненный алгоритм поиска на уровне СУБД.

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

Ну, и зачем Вы снова воткнули пост в ту подветку?

Читать же неудобно! Если Вам кажется, что "надо закругляться" - Ваше право, но я все еще безуспешно пытаюсь ХОТЯ БЫ НАЧАТЬ разговор!
2. Отвечать вопросом на вопрос - моветон. А в цитате Дейта как раз НИЧЕГО не говорится о том, что ключи применяются для ограничений целостности - об этом "говорят" исключительно Ваши голословные утверждения. А вот Дейт говорит,что ключи есть аналог ссылок, т.е. используются ДЛЯ ДОСТУПА! И это тот редкий случай, когда я с ним согласен.
3. А что такое, простите, "свойство"? Или "сущность"? Запрос на естественном языке - это просто "мама", как в Google. Ваш же запрос, в том же Google, дает несколько ИНЫЕ результаты. И ПРАВИЛЬНО ДЕЛАЕТ! Ибо для него все слова запроса есть данные для поиска. В данном же случае "мама" может быть объектом, именем атрибута, значением. Более того, Вы, как пользователь, ничего об этом не знаете, И ЗНАТЬ НЕ МОЖЕТЕ! Так вот: запрос в идеальной СУБД итерационный! Это вопрос СОГЛАСОВАНИЯ понятий клиента и сервера: this или не this. И ответ сервера на Ваш запрос может быть, например, таким: "У меня тут 150 миллионов "мам" - может быть, Вы хотите уточнить запрос? Вот, например: ...
4. В вот это уже тон исчезнувшего "коллеги". Я утверждаю КАТЕГОРИЧЕСКИ, что Вы пока что не поняли НИ ХРЕНА, и вопросов должно бы иметься ДО ХРЕНА. Если Вы намерены становиться в позу обиженного - печально: вопрос важный и сложный, а Вы производите впечатление очень умного человека.(с)

Изображение пользователя Serguei_Tarassov.

Подытожим

Ключи в РМД используются для ограничения целостности по их определению. Дейт говорит об эквивалентности связей в сетевой МД внешним ключам в РМД. Алгоритм поиска "неважно чего" в "любом типе данных" вызвал затруднения. Концепция новой модели данных даже в общих чертах не приведена.

Вывод неутешителен: у вас нет никакой новой концепции и не хватает элементарных знаний по обсуждению концепций существующих. Просьба более не поднимать на нашем сайте никаких подобных тем.

Ого!

Права почиканы, блог уничтожен... спасибо за гостеприимство! ;)

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

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

Я завел две ветки об идеальной СУБД, с двух сторон: физуровня и браузера. Это ПРОСТЕЙШАЯ часть концепций, но даже здесь пока что не просматривается попыток обсуждения именно заявленных мною тем. Тем не менее, обе темы пока что живы - уничтожена лищь "факультативная" статья про браузер, которую и не жаль - так что я отсюда не уйду. Я осознаю, что очень велика вероятность того, что меня просто вышвырнут, но... "делай, что должно, и пусть будет, что будет". Грустно!

Еще раз формулирую набор тезисов на тему "Идеальная БД"

1. Идеальная БД является мультимодельной. Повторяю: НЕ реляционной, НЕ сетевой, НЕ иерархической, НЕ объектной, НЕ какой-либо иной!

2. В идеальной БД хранятся ЛЮБЫЕ оцифрованные данные, ЛЮБОЙ сложности, ЛЮБЫХ объемов, ЛЮБЫХ форматов - структурированные, полуструктурированные, неструктурированные, неоднородные, ЛЮБЫХ базовых типов (INTEGER, LINK, STRING, DATE), ЛЮБЫХ типов, определяемых пользователем (ADDRESS, PERSON, COMPANY). При этом даные БД независимы: любая модификация данных выполняется прозрачно для остальных, т.е. затрагивает только модифицируемые данные, и не требует никакой реорганизации связанных с ними элементов данных.

3. Идеальная БД не имеет фиксированной схемы - процесс реструктуризации есть обычное, рядовое явление, проводимое прозрачно для конечных пользователей. При этом допускается как последовательная (record-by-record), так и групповая работа с данными (по аналогии с РМД). В отличие от РМД, допускаются дубли кортежей, допускаются ссылки не только на кортежи, но и на их отдельные поля, допускаются многозначные атрибуты, или неатомарные поля данных.

4. Идеальная БД является многоуровневой, и в настоящее время мы рассматриваем лишь ФИЗИЧЕСКИЙ уровень, зависящий от реализации. UI посвящена отдельная ветка - здесь рассматриваем только ядро СУБД.

5. Этот уровень обеспечивает ПРЯМОЙ доступ к хранимым данным. Повторяю: НЕ по ключу, а по указателю (в том же понимании термина, как и в программировании). При этом, в отличие от подхода CODASYL, допускаются отношения "многие-ко-многим", а указатели не зависят от природы физического хранения данных и, следовательно, не требуют изменения при модификации данных, или при реструктуризации БД.

6. Физический уровень является сервером для всех вышестоящих уровней: доступ к данным можно получить ТОЛЬКО через него, и никак иначе. Более точно, он является сервером лишь для уровня данных (не зависящего от реализации) - ни один другой уровень доступа к нему не имеет.

7. Элемент данных идеальной БД является непосредственно адресуемой единицей. На логическом уровне его можно рассматривать как один непрерывный байтовый массив, реальный способ физического хранения данных в памяти никого не волнуют - проблемы физического уровня. Доступ - прямой, по имени (идентификатору). С другой стороны, элемент данных можно рассматривать набор полей - как структуру, или кортеж (в реляционном понимании этого термина). При этом размер элемента (скажем, текстового поля), и сам набор полей в любой момент может быть изменен.

8. ЛЮБОЙ элемент данных обязательно имеет собственные метаданные (тег) о его структуре, физическом расположении полей в элементе, типах данных, и т.д. Метаданные могут описывать ограничения целостности, набор допустимых операций, и многое другое. Ограничения целостности на этом уровне касаются только возможной физической порчи данных на внешнем носителе: невозможность интерпретации метаданных тега, ссылка на несуществующее адресное пространство. Такие данные подлежат удалению, если невозможно их восстановление из резервной копии БД.

9. Поскольку семантический смысл полей данных на этом уровне значения не имеет (важен лишь физический адрес полей, и их размер), можно обойтись минимальным количеством типом данных: BYTE, WORD, DW, QW, т.е. поля размером 1, 2, 4 и 8 байт соответственно, а также двумя типами групп: ARRAY (массив полей какого-то из вышеуказанных типов) и STRING (массив полей, оканчиваюзийся специфицированным терминатором).

Вопросы, замечания, предложения?

Еще немного "философии".

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

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

Данные в БД неоднородные: структурированные, неструктурированные, самоописываемые, ссылки, правила, методы обработки данных, и т.д. Поскольку мы сейчас описываем физический уровень, набор типов данных (я их перечислял выше) и описывающих их метаданных весьма невелик. Как и набор возможных операций над данными. Дадим еще несколько определений:

Элемент данных - непосредственно адресуемая единица в рамках всей БД. Адресация осуществляется по идентификатору, который формируется СУБД при создании элемента. В реляционных терминах это кортеж, в графовых - узел, в программировании - структура.

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

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

Обычно при разговоре о базах данных противопоставляют друг другу "поэлементную" и "групповую" обработку данных. Вероятно, это отголоски "Великого Спора" между Коддом и Бахманом. На самом же деле такое противопоставление есть глупость несусветная. По крайней мере, в идеальной СУБД ему не место. Групповая обработка данных (объединение, пересечение, сортировка групп), разумеется, возможна, но... только не на физическом уровне! Точнее, она там тоже есть (например, уплотнение БД), но над нею не властен даже администратор - не его это собачье дело! Все остальные операции физического уровня - поэлементные. Зато - с ПРЯМЫМ доступом к элементу. При отсутствии такого доступа (привет реляционщикам!) всерьез говорить о СУБД не приходится. А вот набор допустимых операций (язык взаимодействия уровня данных с физическим) дадим пока что минимально необходимый: create/delete, read/write.

Вопросы, замечания, предложения?