1. Спасибо, исправлю.)
2. Читал по EAV, многие говорят, что жутко медленно все работает. Да и у меня до 10 групп товаров и у каждого не более 3 атрибутов.
Уменя MySQL, там есть тип json, если в таком поле размешать атрибуты товара, фильтрация будет по ним возможна?
"Почему у тебя на схеме у одного заказа может быть несколько point of purchase?"
Моя косяк, исправлю.)
Может я что-то не понимаю, но суть нормализации разве не в том, чтобы всю информацию хранить в разных таблицах а не в одной, в разумных пределах конечно...
В points_purchase находится адрес магазина в котором совершена покупка (в будущем их будт несколько).
Есть у магазина одна точка прожи (в дальнейшем будет их больше), где покупатели могут сразу приобрести товар (для этого есть таблица points_purchase), а также возможна доставка в другой город (таблица delivery).
Типов товаров будет до 10 (сейчас их 2 на схеме), но у каждого товара свои свойства. Необходимо организовать хранение данных о товаре так, чтобы можно было осуществлять фильтрацию по свойствам.
Оплату храню в отдельной таблице, чтобы в ней содержалась информация (наличный или безналичный расчет) можно еще время платежа добавить. Думаете это лишне?)
points_purchase - информация о заказах в самом магазине, а не онлайн. Если будет несколько точек, информацию хочу в этой таблице держать.
Со скидками пока сложнее, думаю как грамотно реализовать, чтобы можно было скидку установить на весь заказ и на отдельный товар.
Если я буду хранить свойтва товаров в json я смогу делать запросы для фильтрации по одному выбранному свойству?
Прошу еще оказать помощь в хранении товара на складе.
Есть таблица products_in_orders. В ней храняться код товара, его цена и количество товара, чтобы можно было посчитать сумму заказа. Эта таблица свяана составным ключом (код товара и его цена) с таблицей store (склад). Да, так получается, что один и тот же тавар может иметь разную цену (так задумано).
Дальше у меня большие сомнения, что я правильно реализовал хранение данных о таварах на скалде. Есть два типа товара (всего их будет не больше 10) для них созданы отдельные таблицы с уникальными для каждого типа товра атрибтами. Эти таблицы связаны с общей таблицей products, которая связана со скалдом (store).
Такая структруа позволит делать запросы на поиск конкретного типа товара с конкретными атрибутамми?
Какие я грубые ошибки допустил в проектиовании?
Я исправил некоторые Ваши замечания. Убрал отдельную таблицу с адресами и таблицу с телефонами, добавил таблицу с историей статусов заказов, таблицу с оплатой и таблицу с доставкой. Изменил некоторые типы данных полей на более приемлемые (DATETIME вместо DATE и TIME, тип DECIMAL для цены).
Прошу еще оказать помощь в хранении товара на складе.
Есть таблица products_in_orders. В ней храняться код товара, его цена и количество товара, чтобы можно было посчитать сумму заказа. Эта таблица свяана составным ключом (код товара и его цена) с таблицей store (склад). Да, так получается, что один и тот же тавар может иметь разную цену (так задумано).
Дальше у меня большие сомнения, что я правильно реализовал хранение данных о таварах на скалде. Есть два типа товара (всего их будет не больше 10) для них созданы отдельные таблицы с уникальными для каждого типа товра атрибтами. Эти таблицы связаны с общей таблицей products, которая связана со скалдом (store).
Такая структруа позволит делать запросы на поиск конкретного типа товара с конкретными атрибутамми?
Какие я грубые ошибки допустил в проектиовании?
Еесть товары, параметры которых заранее определены, а также склад (таблица store), где где одни и те же товары могут иметь разную цену продажи, в зависимости от закупочной цены.
Ипатьев, есть товары, параметры которых заранее определены, а также склад (таблица store), где где одни и те же товары могут иметь разную цену продажи, в зависимости от закупочной цены.
Клиент делает заказ, разумеется может покупать несколько товаров за один заказ.
Akina, Логика следующая:
1. Необходимо хранить данные о клиентах:
- ФИО;
- дата рождения;
- пол;
- населённый пункт, где он находится;
- номера телефонов и адреса доставки (их может быть несколько).
2. Есть товары, параметры которых заранее определены, а также склад (таблица store), где где одни и те же товары могут иметь разную цену продажи, в зависимости от закупочной цены.
3. Клиент делает заказ, разумеется может покупать несколько товаров за один заказ.
Я правильно понимаю, если мне нужно записать в файл определенный набор бит, то я перевожу их в байты, потом из двоичной системы в шестнадцатеричную и только потом записываю в файл?
Прикольный вроде..., я в цикле проверял все ID пользователей, которые писали боту. bot.get_user_profile_photos(user_id=ID)
где ID - идентификатор пользователя, который беру из своей БД.
Из всех ID в БД, только не возвращает ошибку мой ID.
Вы написали про статичный ID, может в этом проблема?
