Здравствуйте. Я пишу свой интернет магазин -- продажи автодеталей. Возникла сложность с организацией таблиц представления товара. По большому счету я бы мог организовать все топором, но хотелось бы "эстетично" и правильно с точки зрения архитектуры. Итак что мы имеем по детали:
1. ее оригинальный номер (далее ОН), т.е. от официального производителя. например zp05f7
2. кросс номера (далее КН, неофициальные производители). Деталь по кроссу тоже деталь, а следовательно имеет все перечисленные свойства касательно данного описания. Рекурсия.
3. категория детали, например "детали ходовой"
4. подкатегория (стойка стабилизатора)
5. марка авто, например seat. Может быть несколько
6. модель авто, тоже возможны несколько
... цена, наличие и т.д. подробности
Суть проблемы заключается в том что я впал в ступор и не могу построить таблицы так, чтобы оптимально делать выборки. Мне надо чтобы по запросу либо ОН, либо КН, либо подкатегория + марка + модель получить полный список всех деталей, которые связаны между собой. Для этого я мог бы создать одну таблицу с дублирующимися записями и писать простенький запрос к БД. Это неизбежно приведет к огромному объему данных и замедлит работу по выборке из БД. Я прошу вашей помощи, уважаемые специалисты, в организации множества таблиц и связей между ними, чтобы делать выборки можно было прибегнув к связям. Благодарю за трату времени на лонгрид. Что надо прояснить, пишите.

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

982183,
Вы, верно, не поняли сути. frontend реализован на 100%, backend на 70%. Не могу завершить backend пока не организую до конца БД. А вот с организацией БД возникли трудности. В чем я и прошу мне помочь. Благодарю за потраченное на меня время.

Sergueiвероятно вы не понимаете сути ) если есть готовая база и есть вопрос по этой базе - ну так и покажите таблицы и в чем вопрос и чем помочь. А сейчас вы сказали: доктор, у меня это....
Я пишу сразу все по необходимости. Метод снизу вверх. Как пишут на forth'е, например. Сначала дизайн и верстка, а потом backend с БД "штучно". Сначала опцию на сервер сайд, потом таблицу в БД и привязка к данной опции. Код в БД не хранится, только данные. На данный момент есть несколько таблиц, описанных во втором посте, ну и технические, типа клиент инфо, куки и т.д. Я хочу создать таблицу/таблицы с товаром/деталями. Однако сложность в том что для каждой детали может быть:
1. несколько аналогов;
2. несколько подходящих автопроизводтелей;
3. несколько подходящих моделей как одного, так и разных автопроизводителей.
Для выборки лучше использовать целочисленные значения (id, например) просто потому что это на машинном уровне быстрее чем сравнивать строки. А следовательно связывать деталь с аналогами, автопроизводителями, моделями лучше целочисленными ключами. Поскольку хранить массивы в БД категорически неправильно, то надо как-то исхитриться и организовать, например две таблицы (ОН и КН), связать их друг с другом посредством foreign key, но также тем же методом надо еще связать и с автопроизводителями и моделями авто. Допустим связи с двумя таблицами у меня не вызывают вообще никаких вопросов. Но связать сразу несколько таблиц мне совсем непонятно как, равно как и непонятно как делать из таких связей выборки. Также я не уверен что таблиц для товара должно быть две. Я хорошо набил руку в программировании, освоил веб, но опыт с БД имею только на уровне пользователя.
982183Именно принципы организации БД можно посмотреть на готовых проектах.
Может быть я что-то не понимаю? Это веб сайты. Они предоставляют доступ к своим БД? Если так, сейчас nmap в руки и посмотрим, но пары логин/пароль я у них на сайтах не заметил.
KreatorXXIя пока не вижу необходимости плодить таблицы. Может объясните в чём дублирование записей?
См выше.
---
Благодарю всех за внимание к моей проблеме и желание помочь.

Короче, таблицу с переменным количеством столбцов создать нельзя. Типа:
ON1 CN1 CN2
ON2 CN1 CN2 CN3 CN4
Другой вариант -- таблицы с дублирующимися записями, например:
ON1 CN1
ON1 CN2
ON1 CN3
(ON - Original Number, CN - Cross Number)
И это не выход. Почему: например, есть ON1, CN1, CN2, Vendor1, Vendor2, Vendor3. Как видим, вендоров больше, а значит в одной записи будет шлак в кроссах. Пилить костыль по вычленению шлака => архитектурная недоработка. Похоже, пока я тут объясняю то уже начинает вырисовываться общая картина того что надо делать.

kolobok0MrKrapkin, Негативный - наверное стоит привести тут структуру которые Вы мыслите.
Вот именно за структурой я сюда я и обратился. Leonid Kudryavtsev, предложил как раз то что у меня вырисовалось в процессе обсуждения.
Благодарю всех за участие, помощь.

SergueiДля начала почитайте основы проектирования реляционных БД.
Есть что-то конкретное? English включительно.

Sergueiемое! в гугле скорее набирайте! теряете драгоценные минуты. На интуит.ру есть хороший материал
Да ты чертов гений! Как же это я такой идиот не догадался? Вопрос подразумевал отбросить в сторону книги-мусор и обратить внимание на действительно хорошую литературу касательно предмета. Все еще актуален.

Sergueiно по моему вам это не поможет ))))
Это -- очень ограниченный "юмор" от очень ограниченного homo. Вы сразу не догадались в чем вообще вопрос и решили вести себя со мной как с наглым школьником, требующим решение его задачи. Получив внятное объяснение собственной глупости решили сослаться на курсы интуит. Мне вполне хватило бы ФИО автора, сопоставимого в предметной области с такими именами как Таненбаум, Страуструпп, банда четырех и т.д., но Вам догадаться до этого невдомёк, а скорее всего Вы вообще предложите самоучитель, ведь он содержит чуть более полезной информации, чем курсы интуит. Странно еще что Вы видеоуроки в трубе не предложили. Вообще хоть что-то кроме интуита по предмету лично Вами было проработано?

Sergueiясно. Ищите хорошего автора ) удачи. Отвечать не утруждайте себя.

P.S. Но если бы вы потрудились зайти туда и посмотреть, увидели бы что там очень хорошее изложение материала - лучше не найти.
Вообще-то я потрудился и зашел на сайты O'reilly, Williams еще до того как Вы начали менторски меня поучать. Благодарю за внимание. Занавес.