Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > PHP: Базы Данных > Много полей в БД

Автор: JEEN 1.2.2012, 22:50

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

Автор: newbee 1.2.2012, 23:01

Из того, что тема создана в разделе PHP, следует сделать вывод, что БД - MySQL? Цитата(JEEN @  1.2.2012,  23:50 ) В связи с этим интересует вопрос, как база данных себя будет чувствовать? Есть ли какое-нибудь ограничение? Хорошо будет чувствовать, ограничение, если и есть, то на размер целой записи, т.е. объединив несколько полей в одно ты разве что прибавишь себе геморроя. 10000 записей - это такая мелочь, что задумываться об оптимизации не надо, кроме простых вещей вроде индексов.

Автор: JEEN 1.2.2012, 23:08

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

Автор: ksnk 1.2.2012, 23:45

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

Автор: JEEN 2.2.2012, 00:12

ksnk, точне не в базе, а в таблице. Попробую привести пример (на самом деле таблица другая) Таблица "Автомобили" ID | Название | Количество колес | Номер двигателя | Номер рамы | Цвет кузова | Количество дверей | Описание | ... что тут можно разбить на несколько таблиц? Из необязательных только "Описание".

Автор: MoLeX 2.2.2012, 06:17

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

Автор: Gold Dragon 2.2.2012, 07:17

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

Автор: $дмитрий 2.2.2012, 08:00

Цитата Есть ли какое-нибудь ограничение? Цитата There is a hard limit of 4096 columns per table, but the effective maximum may be less for a given table. The exact limit depends on several interacting factors.

Автор: krundetz 2.2.2012, 10:16

Цитата(JEEN @  2.2.2012,  00:12 ) Таблица "Автомобили" ID | Название | Количество колес | Номер двигателя | Номер рамы | Цвет кузова | Количество дверей | Описание | ... что тут можно разбить на несколько таблиц? Из необязательных только "Описание". ну хотябы так: Таблица основных данных о автомобиле autoID | Номер двигателя | Номер рамы Таблица названий автомобилей autoNameID | Название машины Таблица названия цветов colorID | Цвет Таблица второстепенных данных о автомобиле autoID | autoNameID | colorID | Описание ..... Цитата(Gold Dragon @  2.2.2012,  07:17 ) да, без полной структуры не понять.. Тут ещё и логика приложения важна, при одной логике придложенная мной структура выиграет в производительности, при другой проиграет

Автор: $дмитрий 2.2.2012, 10:50

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

Автор: JEEN 2.2.2012, 11:45

Цитата Таблица основных данных о автомобиле autoID | Номер двигателя | Номер рамы Таблица названий автомобилей autoNameID | Название машины Таблица названия цветов colorID | Цвет Таблица второстепенных данных о автомобиле autoID | autoNameID | colorID | Описание ..... плохой пример привел я. Потому что да, с автомобилями так можно разделить, а у меня нет. Потому что названия все уникальные, как и "цвета" вот примерно такая таблица у меня: ого... оказывается 21 поле О_о Цитата   `id` int(11) NOT NULL AUTO_INCREMENT,   `name` varchar(255) NOT NULL, - уникальное в 99%, могут быть совпадения, не запрещено   `type` int(1) NOT NULL, - тут стоит либо 1, либо 0 (например, лыжи - 0, велосипед - 1)   `sostav` int(1) NOT NULL, - аналогично, 1 или 0   `culture` int(1) NOT NULL,  - аналогично, но могут быть 0,1,2,3   `theme` text NOT NULL, - уникальное поле в 90%. Используется 10-300 символов.   `url` varchar(100) NOT NULL, - уникальное в 95%. Ссылка на сайт   `perehod` int(5) NOT NULL, - количество переходов по ссылке   `date_end` datetime NOT NULL, - дата, не уник)   `judges` text NOT NULL, -    `prizes` text NOT NULL, - все 3 поля одинаковые, уникальные, но не обязательные, 30% пустых. Их можно вынести   `dop` text NOT NULL, -    `ok` int(1) NOT NULL, - проверка на модерацию, 0 - все нормально, 1 - не проверял еще   `rating` int(4) NOT NULL, - рейтинг. Есть еще другая таблица, которая записывает каждый голос. Но я дублирую сумму голосов в эту ячейку, чтобы при выводе не считать заново.   `img` varchar(15) NOT NULL, - ссылка на изобраение. Кстати, вот еще поле которое можно вынести, наверно. Поле пустое в 30%   `best` int(1) NOT NULL, - 1 или 0   `money` int(1) NOT NULL, 1 или 0   `vznos` int(1) NOT NULL, 1 или 0   `video` varchar(255) NOT NULL, - ссылка, можно вынесте. Пустое в 90%   `date_add` datetime NOT NULL, - дата добавления   `contact` varchar(30) NOT NULL, - контактные данные, пожмно вынести.   PRIMARY KEY (`id`) ) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=10000 ; итого я бы вынес это: prizes | judges | dop | img | video | contact остается 15 полей

Автор: $дмитрий 2.2.2012, 11:56

Для имитации BOOL лучше использовать тип TINYINT(1) Добавлено через 2 минуты и 56 секунд Цитата итого я бы вынес это: Зачем?

Автор: MoLeX 2.2.2012, 12:04

Цитата($дмитрий @  2.2.2012,  11:56 ) Для имитации BOOL лучше использовать тип TINYINT(1) чем лучше?

Автор: JEEN 2.2.2012, 12:06

Цитата Для имитации BOOL лучше использовать тип TINYINT(1) ну да, бд давно делал, не знал про tinyint. Что лучше boolean или tinyint(1)? Кстати, есть же еще ENUM и SET Цитата Зачем? чтобы небыло пустых ячеек в основной таблице. Не надо? Цитата чем лучше? TINYINT    1 byte INT    4 байта

Автор: Gold Dragon 2.2.2012, 12:15

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

Автор: JEEN 2.2.2012, 12:17

Цитата а в основной таблице сохранять сразу идентификатор.. так и есть. Числа это и есть идентификатор массива array(0=>'Белый', 1=>'Черный'); поэтому много чисел. Добавлено через 8 минут и 6 секунд вот что сейчас вычитал Цитата В теории баз данных говорится о том, что схема базы данных должна быть полностью нормализована. При работе с полностью нормализованными базами данных необходимо применять весьма сложные SQL-запросы, что приводит к обратному эффекту - замедлению работы базы данных. Поэтому иногда для упрощения запросов даже прибегают к обратной процедуре - денормализации.

Автор: $дмитрий 2.2.2012, 12:37

Не нужно нарушать традиции Цитата BOOL these types are synonyms for TINYINT(1) Цитата чтобы небыло пустых ячеек в основной таблице. Не надо? Не надо Цитата В теории баз данных говорится о том, что схема базы данных должна быть полностью нормализована Только не в интернете, тут другие правила

Автор: krundetz 2.2.2012, 12:53

Цитата($дмитрий @  2.2.2012,  10:50 ) Расмазывать по таблицам все подряд не стоит а где размазывание? в первую таблиццу я выделил то по чему можно производить однозначный поиск, хотя опять повторюсь все зависит от задачи, которая ставиться перед системой Цитата(JEEN @  2.2.2012,  12:06 ) boolean или tinyint(1)? одно и тоже Цитата(JEEN @  2.2.2012,  11:45 ) итого я бы вынес это: исходите из задачи, просто выносить чтобы что то вынести, пустая трата времени, поставте задачу, чего вы хотите добиться вынесением Цитата(JEEN @  2.2.2012,  12:17 ) вот что сейчас вычитал опять же повторюсь все зависит от задачи, есть данные которые нужны постоянно, есть такие которые требуються очень редко и т.д. и т.п. а соответственно будут отличаться требования к скорости их обработки.

Автор: ksnk 2.2.2012, 13:03

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

Автор: $дмитрий 2.2.2012, 13:04

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

Автор: krundetz 2.2.2012, 15:21

Цитата(ksnk @  2.2.2012,  13:03 ) Есть еще мнение - "работает - не трогай" Очень правильное мнение. Цитата($дмитрий @  2.2.2012,  13:04 ) Нужно?  Если не затруднит, то давай, я всегда открыт для чужих мнений.

Автор: $дмитрий 2.2.2012, 16:44

Цитата Если не затруднит, то давай, я всегда открыт для чужих мнений.  Это щас пальцем в небо тыкать, потому как: Цитата все зависит от задачи, которая ставиться перед системой Покритикую, разве что для продолжения темы   --- Не вижу смысла создавать таблицу второстепенных данных в таком виде Цитата autoID | autoNameID | colorID | Описание Название авто, как ни крути нам нужно при любом запросе(будь-то страница список авто, подробное описание), оно обязательное для заполнения и не является "Дополнительным свойством". Что оно делает в доп. таблице? Смысл выносить сюда colorID, Описание? Короче все статические хар-ки должны находится в одной таблицы.

Автор: krundetz 2.2.2012, 23:25

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

Автор: $дмитрий 3.2.2012, 06:36

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

Автор: krundetz 3.2.2012, 11:50

Цитата($дмитрий @  3.2.2012,  06:36 ) Вопрос: по какой таблице поиск, по этому полю, будет происходить быстрее и почему? насколько я понимаю все зависит от того по каким полям происходит поиск, какой характер поиска ну, от размера таблицы и от частоты блокировок таблицы при записи в нее, я расматривал последний вариант Добавлено через 5 минут и 29 секунд Цитата($дмитрий @  3.2.2012,  06:36 ) В обоих таблицах есть поле с индексом. опятьже индексы можно сделать по разному

Автор: $дмитрий 3.2.2012, 12:22

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

Автор: krundetz 3.2.2012, 16:03

Цитата($дмитрий @  3.2.2012,  12:22 ) а стоит ли выносить в отдельную таблицу поле/поля по котором будет производится активный поиск? при условии что часть данных в таблице часто обновляется и поиск происходит не по ним, то да стоит, так как существует понятие блокировок на запись и блокировки на чтение Цитата($дмитрий @  3.2.2012,  12:22 ) Ведь индексы у нас хранятся в отдельном файле и не зависят от того сколько там будет столбцов. Поправь если не прав  если мы говорим о MySql то по разному для разных типов таблиц, но здесь суть не в этом где они хранятся, работаю то я с данными, а индексы существуют только для поиска

Автор: $дмитрий 3.2.2012, 18:27

Цитата если мы говорим о MySql то по разному для разных типов таблиц Ну это понятно, давай ограничиваться MyIsam Цитата но здесь суть не в этом где они хранятся, работаю то я с данными, а индексы существуют только для поиска  Индексы же как раз и указывают на конкретное место поиска в файле данных. Вобщем тестировать оба варианта ... чтоб снять вопрос

Автор: ksnk 3.2.2012, 19:38

Цитата(Gold Dragon @  2.2.2012,  12:15 ) у меня маленькое предложение, а не лучше ли некоторые данные вынести вообще в константы которые описать сразу в коде.. Зачем к примеру мне хранить таблицу цветов когда я просто могу сделать массив, а в основной таблице сохранять сразу идентификатор Imho, про цвета - дурацкая идея   . Если кто-то поменяет массив цветов в исходнике - сразу вся база накроется медным тазом. А новое название цвета дизайнеру придумать - раз плюнуть, как и программисту вставить его "по алфавиту" в массив... Можно было бы в отдельную таблицу вынести, если так уж неймется...

Автор: JEEN 4.2.2012, 14:53

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

Автор: krundetz 4.2.2012, 15:57

Цитата($дмитрий @  3.2.2012,  18:27 ) Индексы же как раз и указывают на конкретное место поиска в файле данных. указывают, но вспоминаем про автоблокировки на чтение и на запись

Автор: $дмитрий 4.2.2012, 19:11

Цитата Стоит делать или не заморачиваться?  Не тот случай

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)