у меня есть список запчастей, каждая запчасть может соответствовать нескольким маркам автомобилей,например:

1. амортизатор; форд фокус, опель астра
2. сайлент блок; бмв 5, бмв 3

итд

теперь например, пользователь ищет все запчасти на форд фокус,
вопрос: как правильно организовать базу?

пока я вижу только такие варианты:
1) сделать еще 2 или даже 3 таблицы
----------------------
таблица марки авто:

код. название марки
1. ауди
2. бмв
3. опель
4. форд
----------------------
таблица модели авто:

код. название модели. код марки
1. ауди а6. 1
2. ауди а8. 1
3. форд фокус. 4
4. опель астра. 3
5. бмв 5. 2
6. бмв 3. 2

----------------------
таблица соответствия запчасти и модели авто:

код запчасти. код модели
1. 3
1. 4
2. 5
2. 6

ну то есть у амортизатора код 1 и он соответствует
3. форд фокус. 4
4. опель астра. 3
с кодами 3 и 4
аналогично сайлент блок с кодом 2
соответсвует моделям
5. бмв 5. 2
6. бмв 3. 2
----------------------

теперь запрос:

SELECT * FROM zapchasti
INNER JOIN sootvetstvie ON zapchasti.code = sootvetstvie.zapchasti_code
WHERE sootvetstvie.zapchasti_code = 3

(3 это код модели авто форд фокус)

Правильно?
Если правильно то хорошо, но вот проблема в том что база большая и очень нехочется в запрос дополнительную таблицу включать
подскажите пожалуйста что тут можно сделать?

например такой вариант:
2)

таблица запчастей:
код запчасти. наименование запчасти. список моделей

1. амортизатор; форд фокус, опель астра
2. сайлент блок; бмв 5, бмв 3

SELECT * FROM zapchasti
WHERE model_list LIKE 'форд фокус'


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

Посоветуйте как правильно и как будет быстрее работать?
Заранее большое спасибо!

MasterZiv, спасибо!!

MasterZivНе думаю, что она большая. Она скорее всего маленькая.
Сколько конкретно ?

сейчас 400 000 записей, потом будет 4 миллиона, может больше, но не меньше
я конечно начинающий, судить не могу со 100% уверенностью, но вроде, как мне кажется, немало

=============================================================
MasterZivПридётся. По-другому никак.
Вообще, на будущее -- кол-во таблиц не имеет значение.
Ни в БД, ни в запросе. Пусть их хоть 1000 в БД и
25 в запросе. Наплевать. От этого практически ничего не зависит.
Забудь вообще о таких шорах, как "ой, у меня так много таблиц".


значит количество таблиц в запросе слабо влияет на производительность запроса?
а я почему-то думал что если у меня всего одна таблица в запросе то будет работать намного быстрее
кстати про это особо негде почитать. может подскажете?
именно интересует влияние на скорость выполнения каждой следующей добавленной таблицы и/или конструкций WHERE

=============================================================

MasterZiv> Правильно?
Пока мысли правильные.


тут другие люди по разному написали (что-то вроде "иди вешайся" :-))) )
поэтому я все-таки переспрошу:
значит я все правильно делаю и именно так и надо делать (как в варианте1 )?
и никакого другого варианта кроме 1) в данном случае нет. так?
и надо так просто делать и жить дальше? :)

Программист-ЛюбительДве или даже три таблицы!!! - сильно звучит...
Навскидку для ваших запчастей таблиц будет штук 20-30. Минимум.

ну там по тексту же, речь идет не о всей базе вообще, а о конкретном примере: пользователь хочет найти все запчасти форда фокус.
А вообще, конечно и 20 и 30 таблиц нормально для базы в целом...

так мало кода но уже есть опечатка
вместо
SELECT * FROM zapchasti
INNER JOIN sootvetstvie ON zapchasti.code = sootvetstvie.zapchasti_code
WHERE sootvetstvie.zapchasti_code = 3

должно быть:
SELECT * FROM zapchasti
INNER JOIN sootvetstvie ON zapchasti.code = sootvetstvie.zapchasti_code

WHERE sootvetstvie.MODEL_code = 3


============================

alexeyvgrusik48значит я все правильно делаю и именно так и надо делать (как в варианте1 )?
и никакого другого варианта кроме 1) в данном случае нет. так?
и надо так просто делать и жить дальше? :)Да.

Спасибо!
============================

neodddrusik48кстати про это особо негде почитать. может подскажете?
тут другие люди по разному написали (что-то вроде "иди вешайся" :-))) )


Вешаться отменяется - у тебя есть будущее :)
Читай про индексы и кеширование

Спасибо!

MasterZiv> сейчас 400 000 записей, потом будет 4 миллиона, может больше, но не меньше
400 тыщ в какой таблице? Каких сущностей это кол-во ?

запчастей.
например: сайлент блок на форд фокус, цена 100 рублей
итд

MasterZivУ меня таблица 1 миллиард записей.
я делаю запрос:
select * from mytable order by somefield

Простой вроде бы запрос. и таблица одна. Ну и как ты думаешь, завершится
когда-нибудь такой запрос ?

ну все когда нибудь кончается... но я не знаю
и какой правильный ответ?

MasterZiv
On 05/05/2012 03:16 PM, Dimitry Sibiryakov wrote:

> А по-твоему - нет? Т.е. первая страница, выданная гуглем это вовсе и не результат,
> поскольку остальные 100500 ты ещё не просмотрел?.. Ню-ню...

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


а как можно ли SELECT научить выдавать ответ порциями?
например как выдать первые 10 000 записей я знаю - TOP 10000
а как выдать последующие 10 000 ?