NoSQL — этот термин мы все чаще слышим в современном мире. Насколько эти решения подходят под условия жестокой реальности можно узнать из данного выступления:
NoSQL — этот термин мы все чаще слышим в современном мире. Насколько эти решения подходят под условия жестокой реальности можно узнать из данного выступления:
Работает на WordPress & Автор темы: Anders Norén
Sergei Kuznetsov
Давно думаю заюзать NoSQL для след. задачи, но не могу определиться с выбором подходящего решения.
Имеется набор данных: сотни тысяч товаров от неск. десятков поставщиков. Товары имеют определённый набор свойств, которые очень муторно класть на реляционную структуру, при подключении нового поставщика набор свойств может расширяться. К примеру может быть несколько различных названий одного товара на различных языках. Все эти данные нужно ежедневно апдейтить.
При этом почти все эти данные должны иметь некий уникальный ключ для связок. К примеру в магазине xxx продаётся товар ID: 234324 для него используется название ID: 24343234, сам товар расположен в каталоге id…. и т.д.
Или в данной ситуации лучше оставить ORM и не париться? Сейчас используется более 50 таблиц.
AY
Спасибо за доклад. Компактненько получилось.Чуть бы больше примеров из жесткой реальности (детали многочисленных презенташек twitter итд)
ПыСы NOSQL — not only sql. Более актуальная, современная и не столь шокирующая трактовка.
kaznachei
Сергей,
Я бы смотрел в сторону гибридного решения — документно-ориентированная БД для товаров и реляционная для хранения связей.
Ключи генерил сам использую GUID или пользуяюсь генераторами первичных ключей. autoincrement и иже с ними — зависит от вашей базы.
В реляционной базе вы храните только ключи а все данные товаре в докумено-риентированной БД.
AY,
Cпаcибо за отзыв. Примеры вы без труда найдете на
http://highscalability.com/
http://highload.org/
Sergei Kuznetsov
Спасибо за ответ, я пришёл к примерно такому же варианту гибридного решения, но к сожалению придётся изменить всю логику приложения, что пока неприемлимо.