| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > MySQL > Количество полей в таблице и производительность |
| Автор: 02077461 2.4.2007, 17:30 |
| Привет, у меня возник вопрос по производительности MySQL сервера: есть структура, содержащая много полей. Поля логически разбиты на некоторые группы, в частности адрес_типа1 (7 полей), адрес_типа2(4 поля). Как лучше проектировать систему: 1) все поля в одной таблице, делать выборку по нужным полям. 2) Создать дополнительные таблицы, делать выборку JOIN`ом. И вообще, как влияет количество полей в таблице на производительность сервера?.. Заранее спасибо. |
| Автор: AntonSaburov 2.4.2007, 18:37 |
| Из одной таблицы всегда быстрее вытаскивать данные - но в то же время это редкость - часто приходится делать JOIN. Даже в случае один-к-одному - бывает, что данных не так много в каком-либо столбце и лишняя память съедается. Да и некоторые сервера имеют ограничения на размер записи (соотв-но и количество полей) Надо смотреть по задаче |
| Автор: SergeBS 4.4.2007, 12:12 |
| 02077461, Читай насчет нормальных форм. Т.е. любую книжку по СУБД, в которой есть слова "нормальная форма", "нормализация"... Иначе дров наломаешь. |
| Автор: 02077461 4.4.2007, 15:55 |
| Спасибо за совет. Буду просвещаться. |
| Автор: anurbol 14.9.2010, 08:15 |
| Решил продолжить тему, а не создавать новую. Считаю тему нераскрытой! Люди, очень интересует сабж, очень очень важно. Сейчас проектируется бд, и очень важно решить, будут ли храниться данные, не очень относящиеся друг к другу, в одной таблице но с 100 полями, либо в 2-х логически разделенных но с полями по 50 в каждой? Понятно что второй вариант намного лучше в плане нормализации, однако он потребует очень сильной корректировки движка что очень геморно. Вопрос: как сильно влияет, и влияет ли вообще количество полей в таблице на производительность, даже если не использовать SELECT *, а только SELECT needed_field1, needed_field2, needed_field3 |
| Автор: Akina 14.9.2010, 08:39 |
| Надеюсь, тебе не нужна прописная истина, что "если выбросить из таблицы все поля, не использованные в запросе, будет получена максимальная скорость обработки"? Так вот - твой вопрос без кучи дополнительных данных лишён смысла. На ответ будет влиять как соотношение количества запросов к одной/двум таблицам, так и количество в среднем выбираемых записей, процент кэшированных данных, повторяемость запросов и кэширование результатов, количество клиентов и погода на Марсе ... в общем, ТОЛЬКО опытным путём можно узнать, каково влияние в каждом отдельном конкретном случае. Но и оно может одним махом поменяться от незначительных на первый взгляд изменений. В общем случае - разделение 1:1 следует однозначно рекомендовать, когда существуют устойчивые группы наборов полей выборки, позволяющие не затрагивать одну или несколько частей совокупного набора данных. |
| Автор: anurbol 14.9.2010, 08:44 |
| спасибо за ответ. буду наверное разделять, но это такой геморрой.... |
| Автор: Akina 14.9.2010, 08:49 | ||
Ой, да ладно... в чём? Выполняем разделение данных на несколько таблиц. Пишем вьювы, объединяющие данные и представляющие их так, как будто структура не поменялась (а вьюв 1:1 - однозначно обновляемый). После чего спокойно, не останавливаясь, пишем новый код сразу на новую структуру, а существующий плавно переделываем со старой структуры на новую. Когда всё переделано - просто прибиваем вьюхи. |
| Автор: anurbol 14.9.2010, 08:57 | ||
вот это и есть самое сложное, дело в том что, движок с которым я имею дело, сделан для того чтобы угодить чайникам, чтобы все делалось с админки, поэтому в одной из таблиц столбцы прирастают и убывают динамически. но это не важно. Добавлено через 44 секунды вопрос как бэ закрыт, но ценные советы и ответы будут приветствоваться. |
| Автор: hail 25.9.2010, 14:28 |
| зависит от цели. Если количество данных планируется хранить большое и пользователей много и всем информация нужна сразу и ждать просто не как нельзя - тогда нормализация. Здесь кратко: http://www.wwwmaster.ru/article.php?nart=21 . А если это не проблема - то какая разница. Но делать нормализацию - это красиво |
