Дизайн реляционной базы данных

Ответ 1

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

• Системы с большими таблицами (HBase, Hypertable и т.д.)
• Ключевые ценности магазинов (Токио, Волдеморт, и т.д.)
• Базы данных документов (CouchDB, MongoDB и т.д.)
• Графические базы данных (AllegroGraph, Neo4j, Sesame и т.д.)

Я в основном в графических базах данных, и элегантность дизайна данных с использованием этой парадигмы была тем, что привело меня туда, устав от недостатков RDBMS. Я привел несколько примеров построения данных, используя базу данных графа на этой странице wiki и там пример того, как моделировать базовый IMDB фильм/данные о роли/роли.

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

Отвечая на конкретные вопросы с точки зрения graphdb:

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

Преодоление разрыва: я стараюсь делать это по-другому для каждого случая, основываясь на самом домене, поскольку мне не нужен "ориентированный на таблицу граф" и тому подобное. Тем не менее, здесь некоторая информация о автоматическом переводе из РСУБД в graphdb.

Явные модели данных: я делаю это все время (стиль доски), а затем использую модель так же, как и в БД.

Мисс из мира РСУБД: простые способы создания отчетов. Обновление: возможно, не так сложно создавать отчеты из базы данных графов, см. Создание отчета для базы данных Neo4J Sample.

Ответ 2

Я только начинал с нереляционных БД, и я все еще пытаюсь обвести вокруг него голову и выяснить, какая будет лучшая модель. И я могу говорить только за CouchDB.

Тем не менее, у меня есть некоторые предварительные выводы:

Придумали ли вы альтернативные проекты, которые намного лучше работают в нереляционном мире?

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

Тип документа DB свопирует сложности: SQL имеет негибкие данные и гибкие запросы, документы DB - это наоборот.

Модель CouchDB представляет собой набор "документов JSON" (в основном вложенных хеш-таблиц). Каждый документ имеет уникальный идентификатор и может быть тривиально извлечен по идентификатору. Для любого другого запроса вы пишете "представления", которые называются наборами функций map/reduce. Представления возвращают набор результатов как список пар ключ/значение.

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

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

Дизайн документов чрезвычайно гибкий. Я нашел только два ограничения:

• Храните связанные данные вместе в одном документе, так как ничего не соответствует соединению.
• Не делайте документы настолько большими, что они обновляются слишком часто (например, все продажи компании за год в одном документе), поскольку каждое обновление документа вызывает повторную индексацию.

Но все зависит от разработки представлений.

В альтернативных конструкциях я обнаружил, что лучше работать с CouchDB на порядок работы, чем любая база данных SQL на системном уровне, а не на уровне хранилища. Если у вас есть данные и вы хотите их обслуживать на веб-странице, сложность общей системы уменьшается не менее чем на 50%:

• нет таблиц проектирования (незначительная проблема)
• промежуточный уровень ODBC/JDBC, все запросы и транзакции по http (умеренная проблема)
• простое сопоставление DB-to-object из JSON, которое почти тривиально по сравнению с тем же в SQL (важно!)
• вы можете пропустить весь сервер приложений, так как вы можете проектировать ваши документы, которые будут извлекаться непосредственно браузером с помощью AJAX, и добавить немного полировки JavaScript до того, как они будут отображаться как HTML. (ОГРОМНЫЙ!!)

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

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

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

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

В качестве примера ограничение, подсчеты и суммы легко, но средние значения не могут быть вычислены с помощью представления/запроса CouchDB. Исправить: вернуть сумму и счетчик отдельно и вычислить среднее значение на клиенте.

Удалили ли вы пробел с любыми шаблонами проектирования, например. переводить от одного к другому?

Я не уверен, что это возможно. Это скорее полная редизайн, например, перевод функциональной программы стиля в объектно-ориентированный стиль. В общем, существует гораздо меньше типов документов, чем в каждом документе есть таблицы SQL и больше данных.

Один из способов подумать о том, чтобы посмотреть на ваш SQL для вставок и общих запросов: какие таблицы и столбцы обновляются, например, когда клиент размещает заказ? И какие из них для ежемесячных отчетов о продажах? Эта информация должна, вероятно, идти в том же документе.

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

Вы вообще делаете явные модели данных вообще (например, в UML)?

Извините, никогда не делал UML перед документами DB:):)

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

Пропускаете ли вы какие-либо из основных дополнительных сервисов, предоставляемых RDBMS?

Неа. Но мой фон - разработчик веб-приложений, мы имеем дело с базами данных только в той степени, в которой мы должны:

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

Итак, все, что я сдаюсь, - это то, чего я никогда не видел в первую очередь. Очевидно, что ваш опыт может отличаться.

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

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

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

Я ожидаю, что есть наборы данных, которые лучше сопоставляются с SQL, чем с моделью документа, поэтому я думаю, что SQL выживет.

Но для тех из нас, кто просто хочет простой способ хранения и извлечения данных, и я подозреваю, что многие из нас - базы данных документов (как в CouchDB) - это находка.

Ответ 3

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

Harder:

• Переосмысливает концептуальный уровень, поэтому он "сложнее", поскольку он просто другой. Поскольку вы заранее должны знать свои шаблоны доступа к данным, автоматический перевод не может быть применен. Вам нужно будет добавить шаблон доступа по крайней мере.
• Консистенция не обрабатывается базой данных, но должна быть рассмотрена в приложении. Меньше гарантий означает более легкую миграцию, отказоустойчивость и лучшую масштабируемость за счет более сложного приложения. Приложение должно иметь дело с конфликтами и несоответствиями.
• Ссылки, которые перекрещивают документы (или ключ/значение), также должны обрабатываться на уровне приложений.
• В SQL-типах баз данных есть IDE, которые намного более зрелые. Вы получаете много библиотек поддержки (хотя разбиение этих библиотек делает вещи намного более сложными, чем необходимо для SQL).

проще:

• Быстрее, если вы знаете свои шаблоны доступа к данным.
• Migration/Fail-over проще для базы данных, так как no promises сделана вам в качестве прикладного программиста. Хотя вы получаете возможную последовательность. Вероятно. В заключение. Некоторое время.
• Один ключ/значение намного легче понять, чем одна строка из таблицы. Все (древовидные) отношения уже включены, и могут быть распознаны полные объекты.

Моделирование должно быть примерно таким же, но вы должны быть осторожны с тем, что вы ввели в один документ: UML также может использоваться как для моделирования OO, так и для моделирования БД, которые уже являются двумя разными животными.

Мне бы хотелось увидеть хорошую открытую базу данных OO, хорошо интегрированную с С#/Silverlight. Просто сделать выбор еще сложнее.:)

Ответ 4

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

Например, вы можете обычно читать файл из 10 000 записей и сортировать его в поле менее чем за полсекунды, приемлемое время отклика.

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

Ответ 5

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

Еще одна проблема, с которой возникают проблемы с RDBM, - это обработка ключей истории/времени.