Критерии выбора СУБД

Question

[Goder]

От чего зависит выбор СУБД под задачу? Можете ли вы посоветовать почитать что-нибудь на тему характеристик различных СУБД в более-менее сжатом виде?

Comments

[Тимур Шемсединов]

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

[Goder]

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

Answer 1

[Константин]

Очень от типа проекта, денег + от фреймворка в котором вы работаете…
1. взгляд на БД: хранилище данных, больше ничего другого (мускул, сквлайт (мелкое хранилище данных, для >>локальных<< целей))
2. взгляд на БД: один из модулей (не ли сердце) вашей системы, всё что вы программируете находится внутри базы данных, логика действий и поведения системы. Здесь скорее под руку попадают Оракл, (с небольшой чясти постгрес).

Приведу пример:
Всем знамая мускул: в ней находятся реально 3 вида базы данных: ИнноДБ => трансакции, МайИССАМ => без трансакций и большая скорость + Меморы = огромная скорость работы с данными, но жрёт рам.
Всё это хорошо, но майиссам и меморы работают без трансакций, хоть и быстрые но не надёжные. ИнноДБ ок для трансакций, но немного медленее. к сожалению на мускуле непоставите ядро своей программы в базе данных.

Постгрес:
Трансакционная дб, теоретически всё ок, надёжно работает, всё можно наладить, есть хорошие триггеры, итд итп. но опять-же, ядро программы на её особо не поставишь, неразрешает того много, просторы имён плохо решены. (пг/сквл)

Оракл:
Это, она хоть и не быстрая, но надёжная ДБ. Надёжная в смысле есть трансакции и немного по другому работает с данными. И конечно-же не с бесплатным саппортом. Здесь можно поставить ядро чего-угодно прямо в БД (пл/сквл).

Comments

[Elkaz]

Вы рассмотрели только основные реляционные СУБД, и совершенно не обратили внимание на документоориентированные, которые для автора могли бы больше подойти.

[Михаил]

ну хранить сырой документ в базе… я бы не решися

[trak]

«Оракл:
Это, она хоть и не быстрая, но надёжная ДБ. Надёжная в смысле есть трансакции и немного по другому работает с данными. И конечно-же не с бесплатным саппортом. Здесь можно поставить ядро чего-угодно прямо в БД (пл/сквл).»
Не вводите в заблуждение, Oracle быстр, как меч О-Сенсея. Только его надо уметь затачивать :)

[smileonl]

мускул, сквлайт, постгрес, ИнноДБ, МайИССАМ, ДБ, Меморы, жрёт рам

Бля ну как такое можно читать?

[Константин]

Извеняюсь за транслит английских названий. Писал поздно ночью.

Answer 2

[Тимур Шемсединов]

Для описанной ситуации рекомендую брать Oracle как основную СУБД, могут быть, конечно еще дополнительные базы для оперативных данных за день, кеширующее решение какое-то, чтобы часть данных держать в памяти для быстрого доступа. Но если Вы еще не завязаны на технологиях — берите решение Enterprise класса — Oracle. А языки программирования и технологии выбрали уже? Дело в том, что выбор СУБД очень зависит от того ПО, с которым Вы будете интегрировать свое решение, если Вы потом надумаете навесить там Microsoft BizTalk или SAP или 1С где-то, то об этом стоит подумать уже сейчас, при выборе инструментов, чтобы не менять СУБД и не делать потом костыли в виде ночной копии в другую СУБД.

Answer 3

[Fafnir]

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

Answer 4

[justEli]

www.interface.ru/cafedra/dipl/anos.doc