На данный момент у меня 14 полей в базе дынных и около 10 000 записей. Ежемесячно прибавляется по 100-200 записей.
Скоро еще нужно будет добавлять 4 поля. В связи с этим интересует вопрос, как база данных себя будет чувствовать? Есть ли какое-нибудь ограничение?

Сейчас подумваю над объединением некоторых полей. Например, есть 3 поля типа TEXT. Их можно объединить в 1, но тогда придется регулярками их обрабатывать, наверно, хуже будет?

Из того, что тема создана в разделе PHP, следует сделать вывод, что БД - MySQL?

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

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

newbee, что-то я забыл указать, да, БД - MySQL. Спасибо за ответ) Спасли мне несколько часов работы.

JEEN, Во всей базе - 14 полей? Возможно будет разумно почитать что-нибудь про реляционные базы данных и разбить на несколько таблиц...  

ksnk, точне не в базе, а в таблице. Попробую привести пример (на самом деле таблица другая)

Таблица "Автомобили"
ID | Название | Количество колес | Номер двигателя | Номер рамы | Цвет кузова | Количество дверей | Описание | ...

что тут можно разбить на несколько таблиц? Из необязательных только "Описание".

Вам точно следует почитать про нормальные формы БД.
Полностью таблицу опишите, с типом полей


Это сообщение отредактировал(а) MoLeX - 2.2.2012, 07:40

да, без полной структуры не понять.. Но если простое перечисление, то пофигу сколько полей  (в разумных пределах) Главное индексы правильно сделать, чтоб поиск был "приятным"



Это сообщение отредактировал(а) Gold Dragon - 2.2.2012, 07:17

ну хотябы так:

Таблица основных данных о автомобиле
autoID | Номер двигателя | Номер рамы

Таблица названий автомобилей
autoNameID | Название машины

Таблица названия цветов
colorID | Цвет

Таблица второстепенных данных о автомобиле
autoID | autoNameID | colorID | Описание .....


Тут ещё и логика приложения важна, при одной логике придложенная мной структура выиграет в производительности, при другой проиграет


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

Выносить в отдельные таблицы имеет смысл то что повторяется. К примеру Марка/Модель/Модификация, а индивидуальные хар-ки авто должны быть в основной таблицы. Расмазывать по таблицам все подряд не стоит

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

вот примерно такая таблица у меня:

ого... оказывается 21 поле О_о


итого я бы вынес это:
prizes | judges | dop | img | video | contact

остается 15 полей

Это сообщение отредактировал(а) JEEN - 2.2.2012, 11:46

Для имитации BOOL лучше использовать тип TINYINT(1)

Добавлено через 2 минуты и 56 секунд

Зачем?

чем лучше?

ну да, бд давно делал, не знал про tinyint. Что лучше boolean или tinyint(1)? Кстати, есть же еще ENUM и SET


чтобы небыло пустых ячеек в основной таблице. Не надо?


TINYINT    1 byte
INT    4 байта

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

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

Да, кстати, табличка то в основном числовая...  можно и в одной всё оставить

так и есть. Числа это и есть идентификатор массива
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. Числовые поля не сделать так (по ним поиск идет), а вот тестовые - легко. Стоит делать или не заморачиваться?

указывают, но вспоминаем про автоблокировки на чтение и на запись

Не тот случай