Как максимизировать гибкость разработки / функций при использовании MySQL? - PullRequest
0 голосов
/ 18 ноября 2010

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

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

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

Хотелось бы услышать подобные примеры: я уверен, что это не распространенная проблема

Ответы [ 3 ]

2 голосов
/ 18 ноября 2010

Вместо того, чтобы проектировать вашу базу данных иначе, я бы посоветовал сосредоточиться на коде на уровне, где у вас есть метод для возврата некоторого объекта, который нужен вызывающему коду. Убедитесь, что все записи проходят через один и тот же слой, так как в NoSQL вам может потребоваться обновить индекс / представление при записи, а не делать это автоматически в базе данных.

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

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

1 голос
/ 20 ноября 2010

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

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

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

1 голос
/ 18 ноября 2010

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...