Ну этих колонок точно не будет в WHERE условиях.
Меня интересует, насколько типы данных, хранящиеся отдельно вроде JSON/TEXT замедляют работу с таблицей, даже если не участвуют в WHERE запросе.
Или это преждевременная оптимизация и не стоит забивать голову?

конечно преждевременная оптимизация

Возьми varchar , timestamp и не морочь голову

в тему оптимизации очень рекомендую http://optimization.guide/ (оно не относится конкретно к бд, а скорей к разработке)

Хорошее чтиво. Спасибо

Ухты! Полезный сайт. Будет чем отбиваться, когда у начальства возникнет гениальная идея по оптимизации)

там очень много правильных и полезных мыслей, прежде  чем что то оптимизировать убедись что это узкое место
измерь до оптимизации, пойми что оптмизировать можно по разным показателям, выбери что для тебя приоритетно (узкое место)
только потом оптимизируй ну после незабудь померить вновь увидеть вышел ли на запланированные показатели

все это в легкой форме с примерами из реальной жизни

Спасибо. В копилку к refactoring.guru

Этот сайт писал создатель Рефакторинга. Посмотрите в контактах)

Здравствуйте, есть у меня таблица Cashiers, где у меня сохраняються все продавцы, от туда мне нужно будет достать продавцов, которые работали раньше в определенном магазине (магазинов может быть много), как будет лучше спроектировать запись списка магазинов в которых работал продавец?

Таблица продавцов, магазинов и отношения продавцов к магазинам

нее тут связь nXm не пойдет
потому что может быть что один продавец может два раза в одном магазине работать
плюс надо еще хранить дата устройства и дату увольнения

поэтому как написали выше, таблица продавцов, таблица магазинов, таблица кто и где работал
id | продавец_id | магазин_id | started_at | finished_at(nullable)

всем доброго дня!
ребят вопрос такой - у кого есть опыт с Clickhouse?
нужен небольшой ликбез. Хотим хранить данные по аналитике в нем - встал вопрос архитектуры. У нас все сервисы в авс. выбираем сейчас между redshift и Clickhouse. Так вот по кликхаус вопрос - ктоподскажет - данные в нем хранить стоит сырые и аггрегирывать отдельно либо же сырые данные хранить в динаме(у нас сейчас так организовано) - а агрегацию пихать уже в кликхаус?

Всем спасибо, жду ответы.

Какую выгоду вы ожидаете, храня агрегированные данные в CH?

я хочу узнать как принято делать. работать с сырыми данными либо же уже с агрегированными

выгоду по времени на запрос. если дело в милисекундах - то это вообще не вопрос

Кликхаус создан для агрегации на лету

это спасибо

просто за неимении опыта задаю такие вопросы