3

Какую лучше СУБД выбрать под разработку большого проекта? Mongo DB с ее автоматическим привлекающим внимание тысяч программистов, как пчел на мед, шардингом и вообще современными возможностями? MySQL и аналоги ..? SQLite3? Но у нее есть лимиты памяти баз данных и шардинг никакого смысла в увеличении скорости не придаст.

Алюминиевый Робот
  • 55
  • 1
    А как тут состыкуются большой проект и sqlite? Автор что-то нехорошее мутит. Кхм, кхм. – lampa Nov 18 '12 at 07:30
  • 1
    Вы простите. Я понял уже, что SQLite3 не подойдет. – Алюминиевый Робот Nov 18 '12 at 08:40
  • Mongo DB, как вы, надеюсь, знаете, использует для запросов свой специфичный язык( это, как SQL в MySQL, например, но только не SQL =) ), поэтому придется изучать этот специфичный язык, но зато про атаки типа SQL Injection можно вовсе забыть...но вместе с этим MongoDB несет в себе и другие уязвимости... – Salivan Nov 18 '12 at 09:26
  • Знал. Но надо же когда-нибудь развиваться. Хотя, как я понял Вас, это не развитие, а скорее более удобная модель. – Алюминиевый Робот Nov 18 '12 at 14:20
  • -4
    оракл – kindos Nov 19 '12 at 07:19

8 Answers8

7

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

Документо-ориентированные БД (mongo, couch) будет лучше если в системе вам часто приходится копировать записи с их зависимостями. Или, например, если не все записи имеют одинаковые поля.

Если же вам приходится обрабатывать массивы данных для подсчёта неких статистических данных (например, среднее состояние кассы всех компаний за N-ый период), то здесь к месту реляционный подход (mysql, postgresql).

Поэтому, чтобы сузить круг выбора БД, для начала выберите её тип исходя из поставленной вам задачи.

Яковлев Андрей
  • 1,001
  • Правильный подход. Благодарю. – Алюминиевый Робот Nov 18 '12 at 14:21
  • истина посередине. ) в больших проектах можно разделить данные на SQL и NoSQL базы.. к примеру. справочники, журналы и документы хорошо хранить в NoSQL, в то время как регистры и отчеты в SQL. – MuFF Nov 22 '12 at 05:59
3

Есть большая тройка: Oracle, MS SQL Server и IBM DB2. Все остальное это детские шалости, ну разве что MySQL и Postgres близки к этим гигантам.

Когда вы говорите большой проект, то видимо речь идет не столько о том, что много данных, но видимо и о том, что много серверов, много коннектов. По человечески умеют делать кластеризацию только указанные монстры, а всякая мелочь вроде MongoDB и проч. - не смешите. Ну запихнете вы туда 100 гигов (и то сомневаюсь), а дальше то что? Ну про SQLite вообще умолчу: ключевое слово здесь lite - то есть легкий, маленький. Хорошо, хоть не упомянули про Hypersonic SQL :)

Когда проект большой на первый план выходит не столько способность вмещать данные, столько возможность "держать" нагрузку, использование фич специализированных серверных процессоров, возможность кластеризации, бэкапа, репликации данных между инстансами. Ну и не забываем про поддержку. Какую вы поддержку получите с MongoDB и тем паче с SQLite? Форум полусумасшедших разработчиков-индусов?

В общем смотрите в сторону большой тройки. Я лично, предпочитаю Oracle.

P.S. Почитав про цели:

Ну если говорить о базе жителей города и устройстве у них лк по мониторингу электричества, например.

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

Barmaley
  • 81,300
  • Спасибо за профессиональный совет.
  • И Вы туда же. Я лишь выясняю. Да что там говорить. Главное же, бросить камень в чужой огород из своего.
    • – Алюминиевый Робот Nov 23 '12 at 13:13
  • Да ладно, я уж шутя - не бери в голову... – Barmaley Nov 25 '12 at 15:56