LINUX.ORG.RU

Конфигурируемые обьекты, много и с версиями

 


0

2

Создаю трудное детство 1С.

К продукту будет прикреплён админ, который будет задавать поля для объектов, пряио как типы документов в cms.

В отличии от цмс, записей много, миллиончик-другой. Есть иерархия, но только из объектов разного типа, набор А, каждый А может содержать набор Б, ну или просто в Б есть признак А. И на какой то срез записей, например, все принадлежащие верхнему уровню иерархии или произвольный набор. Нужно на срезы создавать версии, менять внутри данные, сливать, хранить историю. Срезы по 10-50 тыщ.

Какой тип базы и какая структура для этого подходит?

Пока только подсмотрел в цмсине одной, там реляции вида

Objects

– objectTypeId

– parentId

Values

– objectId

– fieldId

– value всех типов

– versionId

Наивное как котёнок Гав. Взлетит или чего получше есть?

Ответ на: комментарий от DumLemming

Не имел с ними дела. Мое понимание такое, что nosql нужен, если ты строишь сервис потрясающего масштаба. Который, ну никак не уместится на одном сервере. Причем постгрес немного умеет в реплики только для чтения, так что тут, скорей, ограничение только на запись будет.

К примеру у stackoverflow масштаб не дотягивает. Им обычной СУБД хватило.

Поэтому в 99.99% проектов постгреса за глаза. И если кажется, что его не за глаза, скорей всего его неправильно используют.

А те, кто делает 0.01%, которым постгреса не хватит, сами меня чему хочешь научат. Но вряд ли они будут на лоре спрашивать что-то.

Большинство применений NoSQL неоправданно и вызвано глупой модой или неоправданным оптимизмом по поводу будущего масштаба проекта. Я знаю только одно хранилище, которое я сам часто использую — это S3. Вот его использовать можно и нужно в нужных местах.

Особняком кеш стоит, очереди, системы полнотекстового поиска. Полагаю, что их с СУБД сравнивать некорректно.

vbr ★★★
()
Последнее исправление: vbr (всего исправлений: 3)
Ответ на: комментарий от ac130kz

Вот. Принял 500 и тоже такие мысли в голову полезли.

Хотя предметных запросов не будет. Ну, почти.

Может наоборот, орм прикинуться? Описание полей хранить, а для хранения данных реальные таблицы создавать, прям из этих описаний?

DumLemming ★★
() автор топика
Последнее исправление: DumLemming (всего исправлений: 1)
Ответ на: комментарий от DumLemming

Орм как раз в таких случаях кажутся пятым колесом, им надо кормить всё чёткое и конкретное. Конечно ормки всё равно удобно можно использовать для всего остального. Поэтому вариант с Postgres + JSON и россыпь логики под орм очень даже жизнеспособный вариант. Можно JSON еще и с метаданными полей вообще сделать.

ac130kz ★★
()