Имеет ли данная схема организации БД право на существование?
Всем привет!
Хочу понять имеет ли право на существование такая схема и какие в ней явные и неявные минусы.
В SQL базе данных хранятся только id (возможно еще числовые параметры, такие как сумма/количество/итд)
Все остальное хранится в NOSQL базе.
То есть (как пример), есть "товар". в SQL базе для этого товара - только колонка ID
В NOSQL базе хранятся все поля этого товара (естественно могут быть разные у разных товаров).
SQL база используется для хранения и выборок со сложными связями.
P.S. То есть, если проще, все свойства объекта хранятся в NOSQL, а все действия с ним - в SQL
Имеет ли такая схема право на существование и, если да, то как наиболее органично ее использовать с ActiveRecord?
а) для более быстрого поиска по продуктом
б) для поддержки локализаций, допустим, наименования продукта на нескольких языках и, при этом, продавец сам выбирает, на каких языках написать. Для этого, без nosql базы, я вижу 2 решения - либо токены (не нравится), либо json поле. Ни то ни другое особо не нравится.
Скажем так, для "быстрого доступа" я решал задачу редиской - в контроллере делаем проверку на присутсвие запрашиваемых данных в редисе, если таковых нет то делаем запрос к базе, отдаём данные клиенту заодно пихаем в редис и ставим лайфтайм где-то на часов 5-7 или если оперативы хватает то и побольше.
Остальные запросы на эти данные будут обслуживаться уже редисом.
Частые запросы закешировали и не напрягаем основную БД, а кому что-то редкое нужно то и напрячься не проблема.
Алексей POS_troi: Кеширование, конечно есть. Но для подсказок при поиске надо делать поиск по всем товарам. Можно, конечно, закешировать только пары name, id
Вообще самая распространенная схема - хранить все и в реляционной базе и по изменению данных запускать агрегацию в nosql. В таком случае у нас есть надежное хранилище, которое хранит все данные, и nosql база хранящая агрегации данных с целью ускорения выборки за счет денормализации. В этом случае в nosql будет много дублирования но нас это не парит так как у нас есть реляционная база, из которой всегда можно хоть с нуля агрегации запилить.
Соответственно у нас появляется разделение - все операции на запись работают исключительно с реляционкой, все операции на чтение - с nosql (ну или часть с nosql и часть с реляционкой, тут смотря что вы хотите ускорять и есть ли смысл в организации агрегации данных).
Спасибо. У нас сейчас так и работает, что nosql для аггрегации, а реляционка, как основное хранилище. Но, видимо, захотелось чего-то сильно изменить :)
Любая схема имеет право на жизнь, пока не начнет безбожно тормозить. Как уже успели заметить в комментариях - Зачем? Вы фактически вместо одного запроса - делаете 2 и в разные источники. Что вам мешает создать таблицу products_description и в ней хранить 3 поля - product_id , locale, и данные в xml или json формате? На вход хранимке 2 параметра - id и локаль , на выход все необходимые данные для постройки формы. Причем если на уровне базы данных целостность внешнего ключа проверять не составляет труда, то как вы собираетесь контролировать данные в двух разных источниках?
Мешает, например то, что речь о локализации не только одного поля, допустим, у продукта неограниченное кол-во полей, которые, опять же, может добавлять сам продавец и каждому этому полю нужна локализация. В таком варианте я не вижу приемлимого выхода с отдельной таблицей, вижу выход только с авто-сгенерированными токенами для этих полей и таблицей локализации для токенов. Сама структура продукта с неизвестным кол-вом полей, как мне кажется, лучше подходит для schemaless баз
Дмитрий Ковальский: Тогда это почти ничем не отличается от json полей в postgresql. Не знаю, почему, но это решение мне не нравится (хотя оно вполне жизнеспособно) :)
Простой
