В крупных проектах для введения точной статистики второй вариант используется?

Если нужно когда-то будет что-то из Products (чего не будет в таблицах статистики), то лучше его мягко удалить. Насчёт крупных проектов не подскажу

Чтобы избежать засорения базы, можно сделать комбинированный вариант из тех двух. И жёстко удалять записи Products, когда они уже точно никакой ценности не имеют и для статистики в том числе.

Понятно)

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

Сколько потребуется времени, и какие навыки нужно оттачивать чтобы быть Про в БД

Мои навыки:
Postgresql, Python

Или все таки нужно нанять спеца в этой области чем самому?

Финансово нет проблем

Со стороны могу сказать, что совет знакомого однозначно дельный - продумать надо все как можно лучше, начиная от бизнес-требований и заканчивая архитектурой БД.
> Мои навыки: Postgresql, Python
Это ничего не говорит мне о Вашей способности построить архитектуру, безопасную и расширяемую, наладить клиент-серверное взаимодействие, о способности анализировать готовые решения (например, CMS-ки интернет магазинов). Лично я бы такой проект сам поднимать бы не взялся, как минимум с достаточно опытным напарником...

Также есть такие понятия, как DDD, паттерны проектирования, TDD. О которых тоже неплохо было бы хотя бы знать, что они есть ;)

Спасибо за годный СОВЕТ

Я сохраню вас в контактах

Пожалуйста, ок)

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

> начиная от бизнес-требований и заканчивая архитектурой БД
Я примерно это и написал. Про ddd и прочее упомянул, потому что человек хочет сделать не только базу а всё приложение (как я понял)

Когда добавляю данные по второй таблице, из-за group by мне не правильно выводит сумму необходимых мне колонок

'''select DATE(a.ForDate) as dzień
,count(a.ForDate) as liczba_rozmów
,sum(count1) as ecs_1
,sum(count2) as liczba_transferów
,sum(count3) as ecs_3
,sum(sms) as smski
,sum(dni) as ilość_dialogue_details
from
(
Select DATE(c.start_time) as ForDate,
 coalesce(sum(case when d.send_sms = 'TRUE' then 1 else 0 end), 0) as sms
 ,count(d.lekta_call_id) as dni
 ,case when end_call_status = 3 then 1 else 0  END count3
 ,case when end_call_status = 2 then 1 else 0 END count2
 ,case when end_call_status = 1 then 1 else 0 END count1
 from "Conversat" c left join dialogues_details d
 on c.lekta_call_id = d.lekta_call_id
 group by DATE(c.start_time), count3, count2, count1
) as a
group by dzień
order by dzień desc;'''

В чем может быть проблема и как исправить? если убрать GROUP by DATE ...count1, и все что к этому относится, считает нормально, но без него не удается соеденить два разных запроса к таблицам

Привет всем, есть таблица юзеры и таблица кейсы, надо найти юзеров не имеющих определенный тип кейса, mysql, таблица кейсов содержит столбцы user_id, casestype

Что такое кейсы?

купленные кейсы(продукты)

то бишь надо найти пользователей не купившие определенный тип продукта