так и есть. Числа это и есть идентификатор массива
array(0=>'Белый', 1=>'Черный'); поэтому много чисел.

Добавлено через 8 минут и 6 секунд
вот что сейчас вычитал

Не нужно нарушать традиции



Не надо


Только не в интернете, тут другие правила

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

одно и тоже

исходите из задачи, просто выносить чтобы что то вынести, пустая трата времени, поставте задачу, чего вы хотите добиться вынесением

опять же повторюсь все зависит от задачи, есть данные которые нужны постоянно, есть такие которые требуються очень редко и т.д. и т.п. а соответственно будут отличаться требования к скорости их обработки.

Это сообщение отредактировал(а) krundetz - 2.2.2012, 12:54

Имеет смысл выкинуть в отдельную таблицу часто повторяющиеся значения. просто для того, чтобы сэкономить  на 'select distinct ...' по этому полю, для вывода возможных вариантов.
Есть мнение, что в некоторых случаях удобнее обойтись без такой операции, а заменить значение на ENUM поле... Экономия даже больше.

Есть еще мнение - "работает - не трогай"   Если менять схему таблицы без особых оснований - можно и проиграть в скорости и удобстве.

Я не комментировал твой вариант. Нужно?

Очень правильное мнение.

Если не затруднит, то давай, я всегда открыт для чужих мнений.

Это щас пальцем в небо тыкать, потому как:

Покритикую, разве что для продолжения темы  

---

Не вижу смысла создавать таблицу второстепенных данных в таком виде

Название авто, как ни крути нам нужно при любом запросе(будь-то страница список авто, подробное описание), оно обязательное для заполнения и не является "Дополнительным свойством". Что оно делает в доп. таблице?
Смысл выносить сюда colorID, Описание?

Короче все статические хар-ки должны находится в одной таблицы. 

$дмитрий я предположил что:

1. Ежесекундно производиться поиск по VIN номерам
2. Данные по VIN переписываются не часто.
3. Также постоянно осуществляется поиск по остальным данным, хотя и реже чем по VIN.
4. Остальные данные изменяются не реже раза в день ( огромная сеть авто сервисных станций описывает все операции производимые с машиной )

Собственно и таблицы предложил разделить, чтобы поиску обслуживался(обслуживается) ли такой автомобиль в мастерской происходил максимально быстро. Запрос же о том на какой стадии ремонт машины в данный момент производился бы по дополнительному запросу только в случае надобности в этом. То есть применяем ленивый алгоритм.

Хотя ты прав насчет идентификатора названия, стоит его перенести в основную таблицу.

Это сообщение отредактировал(а) krundetz - 2.2.2012, 23:27

Интересный момент. К примеру, есть БД(MyISAM) состоящая из 2 таблиц:
1. С 1 колонкой
2. С 50 колонками
В обоих таблицах есть поле с индексом. Вопрос: по какой таблице поиск, по этому полю, будет происходить быстрее и почему?

Это сообщение отредактировал(а) $дмитрий - 3.2.2012, 06:37

насколько я понимаю все зависит от того по каким полям происходит поиск, какой характер поиска ну, от размера таблицы и от частоты блокировок таблицы при записи в нее, я расматривал последний вариант

Добавлено через 5 минут и 29 секунд

опятьже индексы можно сделать по разному

Это сообщение отредактировал(а) krundetz - 3.2.2012, 11:51

Таблицы различаются только кол-вом столбцов, там где их больше ес-но данных(не строк) будет больше. Остальные условия идентичные.
Вот к чему спрашиваю: а стоит ли выносить в отдельную таблицу поле/поля по котором будет производится активный поиск?

Ведь индексы у нас хранятся в отдельном файле и не зависят от того сколько там будет столбцов. Поправь если не прав

при условии что часть данных в таблице часто обновляется и поиск происходит не по ним, то да стоит, так как существует понятие блокировок на запись и блокировки на чтение

если мы говорим о MySql то по разному для разных типов таблиц, но здесь суть не в этом где они хранятся, работаю то я с данными, а индексы существуют только для поиска

Ну это понятно, давай ограничиваться MyIsam


Индексы же как раз и указывают на конкретное место поиска в файле данных. Вобщем тестировать оба варианта ... чтоб снять вопрос

Imho, про цвета - дурацкая идея   . Если кто-то поменяет массив цветов в исходнике - сразу вся база накроется медным тазом. А новое название цвета дизайнеру придумать - раз плюнуть, как и программисту вставить его "по алфавиту" в массив...
Можно было бы в отдельную таблицу вынести, если так уж неймется...

я тут вспомнил, про функцию serialize / unserialize. Числовые поля не сделать так (по ним поиск идет), а вот тестовые - легко. Стоит делать или не заморачиваться?