Как правильно организовать структуру базы данных интернет-магазина, если товары из разных источников?
Всем доброго времени суток!
Очень прошу советов из опыта насчет правильной организации структуры базы данных.
Есть сеть магазинов в разных городах: Москва, Санкт-Петербург, Новосибирск, Екатеринбург.
Компания планирует расширяться и в других городах.
Моменты:
1. В каждом городе своя (полностью отдельная) база 1С в которой хранится информация о товарах.
2. Структура баз 1С хранения у всех одинаковая, поэтому функциональность импорта товаров в БД будет единой.
3. В каждой базе есть свои склады (разбросанные по городу) с разными остатками товаров.
4. Товары в большинстве одинаковые но есть и разные позиции (т.е., например, какие-то товары есть только в Москве). Соотношение примерно 70/30.
5. У товаров есть три типа цены: все, партнеры и оптовики.
6. Примерное количество товаров в базе: 10 000 - 15 000 шт.
7. Сайт будет на несколько городов и в зависимости от выбранного города, должны отображаться товары из определенной базы 1С. Если в городе еще нет филиала, то будут показываться товары из базы по-умолчанию (Москва).
Какие таблицы в БД я планирую создать: product - название, описание, категория, фотографии product_price - цена, тип цены (числовое обозначение пункта 5 выше) warehouse - название склада (создаю в основном для того, чтобы получить id) product_quantity - id склада, количество остатков
А теперь собственно сам вопрос: как мне организовать структуру для нескольких городов?
Сам метаюсь между двумя вариантами.
Вариант 1.
Создать таблицы по списку выше и в каждую добавить поле, например city - которое будет обозначать город из которого выгружена запись. В значении что-то вроде: msk, spb и т.д.
Вариант 2.
За основу взять, например, Московскую базу и для нее создать таблицы выше.
Для остальных городов дублировать таблицы с приставкой города. spb_product, spb_product_price, spb_warehouse, spb_product_quantity и т.д.
DRY (Don't repeat yourself) и вроде второй вариант избыточен, но помимо основных данных, у товаров будет еще куча атрибутов для фильтров и поиска. Скорость выборки на первом месте.
И вот здесь основные сомнения: сделать выборку из 15 000 строк быстрее, чем из 60 000 (и будет больше) с WHERE city='spb'. На старте хотелось бы сделать правильно, чтобы при последующем развитии не упереться и переписываться все заново.
Может быть кто-то уже сталкивался с такой задачей или есть советы?
Заранее благодарен за любую помощь!
И вот здесь основные сомнения: сделать выборку из 15 000 строк быстрее, чем из 60 000 (и будет больше) с WHERE city='spb'. На старте хотелось бы сделать правильно, чтобы при последующем развитии не упереться и переписываться все заново.
Современные бд вообще с такими объемами смешными справляются достаточно легко, скорость может проседать в районе миллиона записей (утрированно, но где-то близко к истине), и там уже надо думать как это хитро индексировать/шардировать или тюнить железо/софт (естественно и тестовая машина должна быть какой-то адекватной конфигурации). По этому такая экономия на спичках по итогу выйдет боком. Собственно вам ничего особенно не стоит создать фейкером 15/60К записей со связями и прогнать эксплэйн на запрос, посмотреть чего в индексах не хватает, как быстро идет выборка... И WHERE city='spb' скорее всего вам аукнется, нужно связывать со справочной таблицей городов и соединять по айди-сити_айди, или через пивот, если у товара может быть больше одного города.
ThunderCat большое спасибо за ответ. Уточните, пожалуйста, почему связь через спровочную таблицу будет лучше? Ведь все равно будет WHERE city='1', где 1 - это city_id. Или плюсом будет связывание таблиц через отношения?
Уточните, пожалуйста, почему связь через спровочную таблицу будет лучше? Ведь все равно будет WHERE city='1',
Во первых будет WHERE `city_id` = 1, а в таблице cities уже будет id (в случае один-ко-многим).
Во вторых, где у тебя будет храниться этот список с твоим spb? Что будет когда добавятся еще города?
В третьих, это путь создания через внешние ключи, что при верном проектировании сохраняет консистентность базы при операциях с ней.
Или плюсом будет связывание таблиц через отношения?
Это и есть связывание через отношение, вопрос только в том какая форма отношений будет, один ко многим или многие ко многим. По сути 3 нормальная форма требует отделения сущностей в отдельные таблицы и связки через отношения.
