Тут-то рабочий график, именно индивидуальные даты. Вплоть до "явился на смену пьяным, ставим прогул" и "вышел на пару дней из отпуска по производственной необходимости".
Такие данные отрывать от работника бессмысленно.Да, но и от даты эти данные отрывать не менее бессмысленно.
Имхо, нормальнее плоской таблицы юзер-дата-тип просто некуда.
Выделение дат с типами куда-то отдельно от юзеров просто не имеет смысла, они отдельно никому не понадобятся.А вот это заведомо неверно. Календарь (соответствие дата-тип) мало того что нужно будет вводить в БД. так его ещё может потребоваться и посмотреть. Или посчитать количество праздничных дней в заданном периоде. Или ещё что...
А смысл дробить эту инфу на две таблицы? Чтобы практически при любом запросе джойнить?Опыт многих программистов говорит о том, что следование нормальным формам практически всегда благоприятно сказывается на всех процессах с данными.
логичнее указывать в клиенте.
При подключении к базе данных нужно тоже кодировку указывать
SHOW VARIABLES LIKE 'char%';
SHOW VARIABLES LIKE 'coll%';
2. Представьте, что в таблицах разное количество записей для товара с неким id. Включая вариант, когда в одной из таблиц вообще нет записи для товара. Что должно вернуться в таком случае?