Дизайн нереляционной базы данных [закрывается]

Работает ли это на любом сервере СУБД?

Ваш ответ здесь всегда будет «нет». Каждая СУБД позволяет настроить собственный порт - MySQL может быть на 1433, 1434 или 99999. Каждая СУБД реагирует по-разному от других СУБД и даже иногда от предыдущих версий самой себя ... Вам придется проверять каждый возможный сетевой порт на каждом компьютер для каждой СУБД (и каждой версии этой СУБД, если они часто меняют строки ответа) и НАДЕЖДА, что они настроили их со стандартными текстовыми ответами, а не зашифрованными и т. Это базовая работа в сети - сначала вы сканируете диапазон IP-адресов, затем вы можете попытаться выполнить сканирование приложений на обнаруженных вами активных портах, чтобы увидеть, как они отвечают на различные запросы, а затем вы используете эту информацию, чтобы сказать: « Вам нужно будет добавить как минимум шаблон доступа.

Проще:

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

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

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

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

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

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

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

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

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

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

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

Фокус дизайна смещается: дизайн модели документа (соответствующий DB table) становится почти неактуальным, в то время как все зависит от проектирования представлений (соответствующих запросам).

Документная БД как бы меняет местами сложности: SQL имеет негибкие данные и гибкие запросы, документальные БД - наоборот.

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

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

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

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

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

Но все зависит от оформления представлений.

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

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

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

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

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

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

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

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

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

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

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

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

Извините,никогда не делал много UML до документных БД :)

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

Скучаете ли вы по какой-либо из основных дополнительных услуг, которые предоставляют РСУБД?

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

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

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

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

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

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

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

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

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

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