| 
|  | | 2.4, edwin (??), 10:24, 18/09/2014 [^] [^^] [^^^] [ответить] | +/– |  |  Простите, у Вас с головой все хорошо, сравнивать слона и носорога ? MongoDB продукт совершенно для иных задач, которые перпендикулярны РСУДБ
 
 |  |  | 
 |  | | 3.5, NikolayV81 (ok), 10:48, 18/09/2014 [^] [^^] [^^^] [ответить] | +1 +/– |  |  Как-то упоминалось, что введение jsonb и доработки сделанные в 9.4 очень сильно остужают желание переходить на MongoDB и тому подобные у многих сомневающихся 
 |  |  | 
 | 
 | 
 
 | 1.8, Аноним (-), 12:49, 18/09/2014  [ответить] [﹢﹢﹢] [ · · · ] | +/– |  | Не могу сказать, что являюсь экспертом по всякого рода БД, но нужность монги и прочих подобных вызывает у меня сомнение. Ведь реляционная структура данных намного логичнее и удобнее для восприятия. Впрочем, это ИМХО. 
 |  |  | 
 
|  | | 2.9, edwin (??), 12:58, 18/09/2014 [^] [^^] [^^^] [ответить] | +2 +/– |  |  > Не могу сказать, что являюсь экспертом по всякого рода БД, но нужность > монги и прочих подобных вызывает у меня сомнение. Ведь реляционная структура
 > данных намного логичнее и удобнее для восприятия. Впрочем, это ИМХО.
 Понимаете, Вы не совсем правы. Есть задачи, когда надо хранить много неструктурированного барахла, причем делать это в режиме active:active на Н серверах и т.д. 
Отличный пример такого рода - Cassandra
 Есть ситуации, когда вообще хранить без гарантии сохранения, в виде key<>value (redis, memcached)
 MongoDB из серии документориентированной БД, именно для хранения неструктурированного барахла (с возможность его нормального индексирования и поиска), хорошо бьется на ноды.
 Короче - это как раз тот случай, когда вся мощь СУБД не нужна
 
 |  |  | 
 |  | | 3.10, NikolayV81 (ok), 16:30, 18/09/2014 [^] [^^] [^^^] [ответить] | +1 +/– |  |  А потом всплывают мелочи, которые бы надо хранить в РСУБД, и тут начинается... 
 |  |  | 
 |  | | 4.15, pavlinux (ok), 03:14, 19/09/2014 [^] [^^] [^^^] [ответить] | +2 +/– |  |  Я за ASCII текст, grep и sed работают быстрее всякой вашей xyеты реляционной. =) 
 |  |  | 
 |  | | 5.16, m1 (??), 12:03, 19/09/2014 [^] [^^] [^^^] [ответить] | +/– |  | у БД есть идексы. Время поиска быстрее перебора. Так же поддерживается система кэша актуальных данных. И касается это не только sql, но так же и nosql (только индексы у них не такие эффективные, так как не всегда данные выровнены по границам структур). 
 |  |  | 
 |  | | 6.17, pavlinux (ok), 16:23, 19/09/2014 [^] [^^] [^^^] [ответить] | +/– |  |  > Время поиска быстрее перебора. Поиск - это задача, перебор - это алгоритм. Теплое и мягкое. 
 Кэш это ваще сказка, - сначала создаём монстроидальне базы, потом победоносно оптимизируем,
структурируем запросы, кэшируем, сегментируем, параллелизируем,... короча ИБД
 Я собственно о том, что очень раздуты проекты использующие SQL.
Тот же 1С, ну когда предприятие из 1000+ человек, столько же заказчиков,
 наименование продукции от ниток для шитья до танкеров,...
 Но блин, вебстраничка какого-нибудь дизайнера, в SQL порядка 50 записей,... ну смешно же.
на выдачу результата от работы связки Apache/PHP/SQL/HTML/JS уходит от 2 до 60 секунд,
 это же пиштец. Посмотрите чудный проект katushkin.ru - тормозилово невроибенское,
 40 сек. до полной загрузки страницы.
 
 |  |  | 
 | 
 | 
 | 
 | 
 | 
 
 |