(по сути считайте ее обычной реляционной БД, суть не изменится) и в ней есть таблица «stories» следующего формата:
id name
1 История 1
2 История 2
3 История 3
4 История 4
Появилась задача сделать так, чтобы можно было выбрать «Историю месяца» - вручную выбираемую историю из таблицы stories, по сути нужно хранить ее id. История месяца будет меняться с периодичностью раз в месяц или чаще, т.е. должна быть возможность без проблем ее менять
Как реализовать подобное в условиях реляционной бд, в которой по сути все является списками? Я думаю, мне было бы удобно хранить подобное в виде KV хранилища, но не в виде списка. Если это так, то как это можно организовать? Из костылей можно сделать таблицу, в которой будет только один объект/запись, выступающий KV хранилищем, но это костыль + мешанина из никак не связанных данных.
Есть какие-то общепринятые практики решения подобного рода задач?
а нельзя сделать таблицу monthly_stories id | story_id | month | year | assigned_at либо вместо month/year - start_date / end_date у вас тогда будет возможность смотреть исторические данные по историям месяца
чисто теоретически можно, конечно, но это избыточно. Мне не нужна эта информация, но ради нее, я так понимаю, мне нужно будет искать в списке историю, у который старт дейт уже начался, а энд дейт еще не закончился. А если там вдруг таких записей 2 будет? (тут уже вернемся к тому, что это CMS, в которую данные вводят манагеры, а они явно не станут думать над тем, что могут что-то сломать)
ну либо не давать манагерам сохранить невалидную сторис если это позволяет cms либо можно хранить только дату присвоения истории статуса "история месяца" и брать всегда последнюю (индекс по assigned_at и всегда первый айтем берем)
мб оконные функции подойдут
ну это ж список ради списка) А мой вопрос как раз в том, как мне в условиях того, что все - это список, хранить то, что списком по сути быть не должно. А по поводу такой сложной валидации - не думаю, что CMS позволит такое сделать
погуглю, спасибо, не слышал об этом ничего
Обсуждают сегодня