Когда пора менять базу данных?

Question

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

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

1. Плоские файлы
2. BDB
3. 1010 * SQLite *
4. MySQL
5. PostgreSQL
6. SQL Server
7. Oracle

Answer 1

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

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

Answer 2

Если вы думаете, что вам когда-нибудь понадобится один из тяжеловесов (SqlServer, Oracle), вам следует начать с одного из них в начале. Миграция данных чрезвычайно сложна. В конечном итоге вам будет стоить меньше, если вы начнете с вершины и останетесь там.

Answer 3

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

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

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

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

Answer 4

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

Теперь еще одно место, где я работал, использовало MySQL просто потому, что данные были нормализованы, стандартные данные строка за строкой.

SQL Server долгое время имел ограничение базы данных в 4 ГБ (см. SQL Server 2000), но, несмотря на это ограничение, он остается очень стабильной платформой для небольших и средних приложений, для которых удаляются старые данные.

Теперь, работая с Oracle и SQL Server 05/08, все, что я могу вам сказать, это то, что если вам нужен крем для урожая для стабильности, масштабируемости и гибкости, то эти два - ваш лучший выбор. Для корпоративных приложений я настоятельно рекомендую их (просто потому, что именно это мы используем там, где я сейчас работаю).

Другие вопросы для рассмотрения:

• Языковая интеграция (хранение сеансов ASP.NET, управление ролями и т. Д.)
• Типы запросов (Выбрать, Обновить, Удалить) [Хотя это скорее проблема проектирования схемы, а не проблемы СУБД)
• Требования к хранилищу данных

Answer 5

На этот вопрос нет полного ответа, но ПОЧТИ всегда, использование плоских файлов не является хорошей идеей. Вы должны разобрать их (я полагаю), и они не хорошо масштабируются. Хорошей идеей будет начать с правильной базы данных, такой как Oracle или SQL Server (или MySQL, Postgres, если вы ищете бесплатные опции). За очень небольшие накладные расходы вы сэкономите много сил и головную боль в дальнейшем. Они также позволяют вам структурировать ваши данные не глупо, позволяя вам думать о том, ЧТО вы будете делать с данными, а не о том, КАК вы будете получать / выводить их.

Answer 6

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

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

Answer 7

И давайте не будем забывать о требованиях, которые должен иметь «заказчик» вашего решения. Если вы пишете коммерческое приложение для небольших компаний, то Oracle может оказаться не лучшим выбором ... но если вы пишете индивидуальное решение для крупного предприятия, которое должно обмениваться данными между несколькими кампусами и имеет большой ИТ-отдел, то Решение Oracle vs Sql Server сводится к тому, что клиент, скорее всего, уже развернул.

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

Answer 8

А как насчет FireBird? Где это вписалось бы в этот список?

Answer 9

Этот вопрос действительно зависит от вашей ситуации.

Если у вас есть контроль над сервером, на котором вы развертываете, и вы можете установить любые необходимые вам службы, то время для установки сервера MySql или MSSQL Express и кода для существующей структуры базы данных VERSUS-кодирование для структуры плоских файлов стоит усилий рассмотреть.

Answer 10

Эта прогрессия звучит больно. Если вы собираетесь куда-либо включать продукты MS (особенно платный SQL Server), вы также можете использовать весь стек, поскольку вам нужно будет заплатить только за последний из них:

SQL Server Compact -> SQL Server Express -> SQL Server Enterprise (clustered).  

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

Также: вернитесь и проверьте SO подкасты. Я думаю, что они говорили об этом кратко.