А вы все NoSQL да NoSQL

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

man mysqldump

там есть разные варианты, в случае InnoDB вполне можно добавлять новые транзакции в процессе снятия дампа

инкрементальные бэкапы легко делаются diff-ом между последним и предпоследним бэкапом :)

Клара Клипперовна Фокс

Я, думаю, не сильно удивлю уровнем некромантии, но «Документы ПУ5» для ПФР - Clarion, «Налогоплательщик» - ФП, и много софта у меня на клиппере, который уже третий год внедряемая сиране odin ass заменить не может...

На реплике?

use Hibernate (или какой-нибудь другой умный ORM). Будет по одному объекту «на каждый тур и на каждый отель»

В том-то и дело, что объектов у меня гораздо больше. Только вот взаимосвязи между сущностями внутри сущностей «Тур» и «Отель» наружу выносить в моей задаче совершенно не нужно.

Что-то мне подсказывает, что ты не осилил реляционную парадигму...

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

в CoudbDB можно спокойно хранить файлы прямо в базе данных

Из батона чёрного хлеба можно сделать троллейбус, НО ЗАЧЕМ?!

Затем, что использование двух независимых хранилищ данных в одной системе (MySQL + FS) существенно повышает сложность всей системы. А CouchDB позволило мне держать все в одном месте и соответственно проще этим управлять.

О боги... Наличие FS повышает сложность системы...

О боги... Наличие FS повышает сложность системы...

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

хаватыру

не распарсил

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

не распарсил

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

торчать на одном проекте - наф

Правильно. Слабал говно на коленке, по-бырому сдал, и дальше пошёл, другое говно лабать. А мы потом удивляемся, почему компы стали на два порядка мощнее, а те же задачи выполняются с той же скоростью.

причём будет гордиться тем, что оно якобы заточенно под его нужды.

тупой троллинг не по теме. А цена вхождения меньше, да. Отсюда и бОльшее кол-во проектов.

он лочит базу на время выполнения

как запустишь, man mysqldump. Он даже может дампить базу в пределах одной транзакции (mysaim это не касается) чтобы таблицы были консистентны.

postgres не маштабируем вообще.

масштабируем на селекты.

А мы потом удивляемся, почему компы стали на два порядка мощнее

Это называется временно-финансовые показатели. Есть идея , есть срок допустим 2 месяца. В срок можно уложиться именно в рамках таких решений. Но можно и конечно потратить 2 месяца на одну только проектировку, а потом ещё 3-4 месяца на реализацию. Да будет качественней и менее ресурсоёмко. НО

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

2. ЗП хорошего программиста за 3-4 месяца может быть вообще космической в сравнении с 2 месяцами среднего кодера.

3. Через полгода свежие идеи могут просто затерятся среди конкурентных наколеночных решений.

Т.е. в при «правильном » подходе клиент финиширует на 4 месяца позже, с бОльшим минусом по финансам + если ему понадобится что-то поменять, пятидолларовым фрилансером тут проблемы не решить, скорее завалить всё к чёрту.

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

Наличие FS повышает сложность системы...

Именно. Поэтому всякие ораклы поддерживают установку на raw partition. И не только ораклы.

Т.е. в при «правильном » подходе клиент финиширует на 4 месяца позже, с бОльшим минусом по финансам + если ему понадобится что-то поменять, пятидолларовым фрилансером тут проблемы не решить

Короче говоря, при правильном подходе капиталист получает меньше денег.

Так то оракл. Ему до файлов дела нет. А мы говорим именно о хранении файлов. Настоящих.

а, ступил

Что-то уже не первый человек говорит об «абсолютно другой области применения», но не может её назвать.

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

1. NoSQL - это простое key-value хранилище. функции map-reduce лишь помощник для обработки данных. здесь все до примитива просто - есть ключ, а есть привязанное к нему значение.

2. СУБД - реляционная алгебра, с богатыми инструментарием _управления_данными_ - тригеры, функций ограничений (по-функции или уникальность), индекс по нескольним полям, внешние ключи, мат.вьюхи, сиквенсами, атомарными операциями и т.д.

и после этого вы хотите сказать, что области применения у этих инструментов одинаковые? хотя да, лопата яму роет и экскаватор тоже - конечно же это одна область :D

см мой ответ чуток выше

простое key-value хранилище.

[code=sql]
CREATE TABLE nosql_can_blow_it (
id BIGSERIAL PRIMARY KEY,
value BLOB
);
[/code]

И?

что И? как я уже писал выше про лопату и экскаватор... никто не запрещает лопатой рыть котлован и экскаватором - ямку. Вопрос в другом, какими эпитетами потом вас наградят «последователи ваших наработок».

или ваш пост о том что nosql не нужен? не соглашусь. он нужен в тех местах, где нужна скорость. в СУБД транзакционность - лютый тормоз на мелких и многочисленных операциях.

Короче говоря, при правильном подходе капиталист получает меньше денег.

Если о качестве и ограниченных ресурсах изначально речь не шла то да. Хотя по опыту - даже когда идёт, всё равно может оказыться что работа идёт по цепочке оутсорсер->сторонний манагер->реселлерN->заказчик и всем кто левее заказчика на качество по-хорошему насрать.

И где в этом комментарии указаны области применения?

И заказчику тоже насрать, на самом деле.

Вопрос не в выразительности, а в производительности. SQL не является панацеей.

НО ЗАЧЕМ?!

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

Если мне не изменяет память то вы повторяетесь.

ну ты и блондинка

а почему бы их не выкинуть?

причём будет гордиться тем, что оно якобы заточенно под его нужды.

тупой троллинг не по теме

Не троллинг и, судя по реакции, вполне в тему.

да я свои программисткие навыки не переоцениваю.

И глупо ругать хорошую технологию или концепцию только потому что кто-то ей не умеет пользоваться.