Вообщем у меня такой вопрос, как понятнее разъяснить заказчику, что от этого нехило возрастает нагрузка на сервер?
Или убедите меня в том, что они поступают верно.
Спустя 34 минуты, 55 секунд (20.11.2009 - 15:09) sergeiss написал(а):
Мне так кажется, что ты прав.
В случае выбора из одной таблицы находим нужную запись, и выводим ее за один заход.
В случае нескольких таблиц надо искать записи во всех таблицах. Плюс к этому, понадобятся индексы для "дополнительных" таблиц. Что потребует дополнительного (лишнего) места на диске. Всё это приведет также к лишним дисковым операциям, в частности, на поиск нужных индексов (3 индекса вместо одного).
Да и при записи уйдет времени больше...
В случае выбора из одной таблицы находим нужную запись, и выводим ее за один заход.
В случае нескольких таблиц надо искать записи во всех таблицах. Плюс к этому, понадобятся индексы для "дополнительных" таблиц. Что потребует дополнительного (лишнего) места на диске. Всё это приведет также к лишним дисковым операциям, в частности, на поиск нужных индексов (3 индекса вместо одного).
Да и при записи уйдет времени больше...
Спустя 2 минуты, 25 секунд (20.11.2009 - 15:11) Иван написал(а):
Спасибо за развёрнутый ответ, заказчика переубедил 
Спустя 30 минут, 45 секунд (20.11.2009 - 15:42) waldicom написал(а):
Но в случае с одной таблицей нет нормализации данных+редундантные данные+не поддерживается целостность данных, следовательно надо следить за этим самому. А выборка по правильно построенным индексам не такое уж и долгое дело.
Хотя конечно такой вариант тоже иногда выбирают в определенных случаях.
Хотя конечно такой вариант тоже иногда выбирают в определенных случаях.
Спустя 36 минут, 33 секунды (20.11.2009 - 16:18) sergeiss написал(а):
| Цитата (waldicom @ 20.11.2009 - 16:42) |
| Но в случае с одной таблицей нет нормализации данных+редундантные данные+не поддерживается целостность данных |
Не понял... Особенно про целостность данных. Это как раз с 3-мя таблицами за ней следить надо "в оба глаза".
Да и про другое, что ты имеешь ввиду, тоже не понял.
Спустя 1 час, 20 минут, 34 секунды (20.11.2009 - 17:39) glock18 написал(а):
waldicom
Поддерживаю.
sergeiss, ты не прав насчет целостности абсолютно.
Иван
разбить на три таблицы может иметь смысл, если по таблицам text и т.п., которые планируется вынести отдельно редко требуется выборка. То есть если в большинстве случаев, достаточно каких-то не слишком "текстовых" данных, то это текстовые данные можно вынести.
Если дело касается mysql, то при большом количестве текстовых полей в одной таблице и разбитых на несколько, он может их джойнить быстрее, чем брать все из одной здоровой таблицы. при условии, что джойн по основному ключу.
Поддерживаю.
sergeiss, ты не прав насчет целостности абсолютно.
Иван
разбить на три таблицы может иметь смысл, если по таблицам text и т.п., которые планируется вынести отдельно редко требуется выборка. То есть если в большинстве случаев, достаточно каких-то не слишком "текстовых" данных, то это текстовые данные можно вынести.
Если дело касается mysql, то при большом количестве текстовых полей в одной таблице и разбитых на несколько, он может их джойнить быстрее, чем брать все из одной здоровой таблицы. при условии, что джойн по основному ключу.
Спустя 2 часа, 17 минут, 32 секунды (20.11.2009 - 19:57) sergeiss написал(а):
glock18 - насчет целостности - почему я не прав? Если мы берем таблицу, разбиваем ее на несколько таблиц, и при этом получаем в каждой одинаковое количество строк... Добавляем еще колонки к 2-м таблицам для связи таблиц. И при удалении нужно обеспечить целосстность данных, т.е. чтобы удаление было сделано синхронно в 3-х таблицах.
В случае же с одной таблице нету никакого такого гимора. О чем я и говорил, вобщем-то.
Насчет скорости... Не буду утверждать однозначно.
В случае же с одной таблице нету никакого такого гимора. О чем я и говорил, вобщем-то.
Насчет скорости... Не буду утверждать однозначно.
Спустя 10 минут, 38 секунд (20.11.2009 - 20:07) waldicom написал(а):
Берем простой пример:
школа, учителя и ученики. Все пихаем в одну таблицу. Получаем примерно такое:
На этом простом примере видно, что данные ненормальзованы+ редундантны.
Теперь попробуем, для примера, удалить учителя2, потому что он уволился. Что получиться? И так далее по схеме.
школа, учителя и ученики. Все пихаем в одну таблицу. Получаем примерно такое:
Школа1 - Учитель1 - Урок1 - Ученик1
Школа1 - Учитель1 - Урок1 - Ученик2
Школа1 - Учитель2 - Урок1 - Ученик3
Школа1 - Учитель1 - Урок2 - Ученик1
..............................................................
На этом простом примере видно, что данные ненормальзованы+ редундантны.
Теперь попробуем, для примера, удалить учителя2, потому что он уволился. Что получиться? И так далее по схеме.
| Цитата |
| И при удалении нужно обеспечить целосстность данных, т.е. чтобы удаление было сделано синхронно в 3-х таблицах. |
За такими вещами в правильно сконструированных таблицах следит сама БД (foreign keys)
Спустя 5 минут, 16 секунд (20.11.2009 - 20:12) sergeiss написал(а):
waldicom - в изначальной задаче речь шла только о том, что простое "тупое" разделение таблиц должно (может) привести к увеличению производительности. Слов про совпадающие значения не было, поэтому надо предполагать, что все эти значения уникальные. Т.е. рассматривать задачу в самом общем виде.
А любые контроли целостности, что ручные, что автоматические, будут требовать ресурсов процессора. Что всяко дольше, чем удаление одной записи из единственной таблицы.
А любые контроли целостности, что ручные, что автоматические, будут требовать ресурсов процессора. Что всяко дольше, чем удаление одной записи из единственной таблицы.
Спустя 40 минут, 31 секунда (20.11.2009 - 20:53) waldicom написал(а):
| Цитата (sergeiss @ 20.11.2009 - 19:12) |
| А любые контроли целостности, что ручные, что автоматические, будут требовать ресурсов процессора. Что всяко дольше, чем удаление одной записи из единственной таблицы. |
Сергей, это просто неправильно, потому что это неправильно.
Кто будет следить за тем, что записи уникальны? Кто будет следить, чтобы не случались аномалии CRUD? Как я смогу удалить запись, если нет первичных ключей? Просто ответь для себя на эти вопросы и ты поймешь, что (к счастью/к сожалению) в данном вопросе ты не прав.
Хотя еще раз подчеркну, что иногда прибегают к подобного рода решениям.
пысы. еще раз прочитал вопрос. Смотри, в вопросе есть такое:
| Цитата |
| вот они говорят, что, чтобы больше влезло надо бы распределить некоторый текстовые поля типа TEXT и VARCHAR по отдельным таблицам |
ты считаешь, что грамотное построение таблиц не достигнет этого результата?
Спустя 30 секунд (20.11.2009 - 20:54) glock18 написал(а):
Удаление записей по внешнему ключу такая мелочь по сравнению с поиском по миллионной таблице с несколькими текстовыми полями