IG
проще второе
там не в классах дело - есть данные, которые лучше хранить в разных коллекциях,
а классы - это представление данных или возможно их части в языке
Size: a a a
2020 February 19
MB
Ну вот я и додумался только до того, что положить их в разные таблицы, а в коде просто двумя запросами доставать всех
MB
в постгресе можно таблицы наследовать
Вот это интересно, надо почитать)
MP
в постгресе можно таблицы наследовать
это типа более компактный способ описывать разные, но похожие таблицы
MB
Либо модель EAV, либо джейсоничики в базе
EAV это кажется что-то противоестественное)
MP
Ну вот я и додумался только до того, что положить их в разные таблицы, а в коде просто двумя запросами доставать всех
и еще надо сильно подумать, прежде чем языковое наследование проецировать на бд, особенно реляционную
MP
EAV это кажется что-то противоестественное)
это хорошее, но довольно медленное
MB
и еще надо сильно подумать, прежде чем языковое наследование проецировать на бд, особенно реляционную
Вот это и странно, потому что довольно часто в коде это именно то, как стоит представлять логику. А на уровне бд это ломается..
Д
это типа более компактный способ описывать разные, но похожие таблицы
ну так если класс представить как таблицу, то sealed классы идеально ложатся на наследуемые таблицы
IG
с EAV проблемы с типами начинаются.
IG
проще хранить id, entity_type и произвольное json-тело
IG
код обмазать спеками, чтобы не пролезла хрень
MP
вся хрень начинентся, когда хочется искать по частям джсона или что-то в нем немного модифицировать
MB
В общем, видимо такой кейс это сразу NoSQL
MP
в постгресе это уже более-менее делается, но страшноватенько с непривычки
IG
немного страшно, да, но можно написать обвязки для honey
MP
немного страшно, да, но можно написать обвязки для honey
а видел что-то такое сделанное?
MP
я так-то весь в монге сижу, но вспомнить постгрес иногда хочется
IG
я знаю что специально для PG выпустили контриб к honey
IG
вот только есть ли там json-операторы, не смотрел.