Являются ли отношения медленнее, чем большой неэффективный стол?

В своей работе меня просили нарушать первую нормальную форму (повторять группы по столбцам, используя пустые / нулевые значения) несколько раз, «ради вычислительной мощности компьютера». В двух словах, в таблице «ученик» должно быть как минимум 8 пустых полей (например, телефоны: phone1, phone2, phone3 ...) вместо моего предложения - таблица «телефон», которая содержит номер телефона (и возможные другие метаданные) и внешний ключ - идентификационный номер студента. Мой начальник говорит, что лучше хранить их таким образом, потому что «меньше циклов ЦП, и это важно для веб-платформ», а не с помощью отношений. Я говорю, что в худшем случае это незначительно.

В этом примере использование отношений (предположим, что таблицы заполнены большим количеством записей в веб-приложении среднего размера) заметно медленнее, чем использование такой схемы таблиц?

— AeroCross
источник

Я полагаю, что на самом деле это было бы быстрее, чем говорит ваш начальник, но у вас есть, возможно, мучительная задача - гарантировать, что вы не получите аномалии обновления. Но это может создать гораздо больше работы процессора, если вам когда-нибудь понадобится изменить часть данных, которая является общей для таблицы (аля изменить код города для всех телефонных номеров ...)

— Патрик

Я серьезно сомневаюсь, что на современном оборудовании, если вы проиндексировали свои внешние ключи, что дополнительный ЦП будет даже измерим, особенно на другой стороне веб-сервера. На моем сайте у нас есть нормализованные таблицы, которые обслуживают к северу от 50 000 ударов в секунду, не потревожив. Скажите своему боссу, чтобы он оставался в гольфе и оставлял вам технические решения!

— Гай

@ Патрик Верите ли вы, что это значительно быстрее или просто немного быстрее? И я думаю, так же, как @Gaius - на современном оборудовании, даже если оно «быстрее», выигрыш в скорости и долговечности оборудования незначителен.

— AeroCross

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

— Патрик

Я не понимаю, как кто-то может сделать такое заявление, не имея реальных фактов, подтверждающих это. Если ваши запросы связаны с центральным процессором, вам следует искать способы уменьшить это узкое место.

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

Я ожидал бы, что такой денормализованный дизайн может привести к уменьшению процессорного времени, но можно ожидать, что ваш дисковый ввод-вывод увеличится. А физическое чтение с диска будет намного дороже, чем цикл ЦП, поэтому, возможно, у вашего босса есть очень специфическая метрика (ЦП), и в результате он хочет иметь очень специфический дизайн? Если это так, я просто построил бы то, что требуется, и сохранил бы метрики стоимости процессора для выполняемых запросов. Если вы видите увеличение во времени, вы можете предложить некоторые изменения дизайна.

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

— SQLRockstar
источник

Дело в том, что он - старая школа - в его дни (20 лет?), Возможно, это было БЫЛО важным, как он предлагает, но современное аппаратное и программное обеспечение намного, намного мощнее, и, по замыслу, быстрее таким образом. Трудно иметь дело с кем-то вроде этого, потому что он обладает большей властью и эмпирическим (но устаревшим) «фактом», что это быстрее, и это следует рассматривать таким образом.

— AeroCross

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

— SQLRockstar