Паттерны программирования и PHP

Цитата ("raznomir"):

в вебе намного меньше ограничений

Вопрос на засыпку .
Чем ограничения работы с БД в вебе отличаются от тех же ограничений в не вебе?

Одно из них - в вебе сервера в разы мощнее большинства пользовательских компов. Потому многие считают обязательным набыдлокодить.
Большинство даже не знает, что echo "date" тратит больше времени, чем echo 'date'. Другие отмазываются тем, что там тысячные доли секунд только выигрываются. Но забывают, что 10000 пользователей + поисковики, да все помноженное на сотни таких echo дают уже гораздо больше нагрузки. И так во всех случаях. Стараются везде и во всем использовать наименее оптимизированные функции.

Цитата ("tvv"):

1. Надежность. ...

... а еще может сгореть дата-центр...

Ну вот прочитал все, что Вы написали тут, - такое впечатление, что вот взяли какую-то из книжек по теории баз данных, и оттуда перепечатали стартовую страницу - уж больно похоже.
А когда разговор переходит в такое русло - обычно он уже не имеет смысла, ибо холивар...

Цитата ("elosoft"):

Чем ограничения работы с БД в вебе отличаются от тех же ограничений в не вебе?

В мышлении, в первую очередь.

Цитата ("raznomir"):

... а еще может сгореть дата-центр...

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

Цитата ("raznomir"):

Цитата:

Цитата (elosoft):
Чем ограничения работы с БД в вебе отличаются от тех же ограничений в не вебе?

В мышлении, в первую очередь.

А конкретнее? Из всего выше сказаного можно только 1 мораль вывести: в вебе надо писать экономно, а в локале - как получиться. А вам не приходилось видеть локальный сервер БД, обрабатывающий примерно по 1000 запросов в минуту?

Цитата ("raznomir"):

Ну вот прочитал все, что Вы написали тут, - такое впечатление, что вот взяли какую-то из книжек по теории баз данных, и оттуда перепечатали стартовую страницу - уж больно похоже.

Это — лишь знания, из головы... если бы я открыл книгу, то можно было бы написать в несколько раз больше аргументов.
Хотя в любом случае, спасибо за комплимент.

Цитата ("raznomir"):

А когда разговор переходит в такое русло - обычно он уже не имеет смысла, ибо холивар...

Ваша позиция понятна. Холивара я тут не вижу, зато вижу, что возразить мне Вам просто нечем. Или я ошибаюсь?
Может быть все же попробуете написать ответы, по каждому приведенному мной пункту?

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

Цитата ("tvv"):

Может быть все же попробуете написать ответы, по каждому приведенному мной пункту?

Пункты 1, 3 и 5 Вашего списка важных принципов организации БД элементарно выдерживаются и в иных вариантах реализации, а не только "канонических".
Пункт 2 и 4 - уже не вижу смысла выдерживать, более того, если Вы почитаете другие умные книжки (поновее), а также подключите и логическое мышление, то обнаружите, что правильно построенная избыточность и дублирование данных как раз повышает надежность и целостность БД, а также скорость работы с ней.
В частности, если у нас есть вычисляемые значения, что редко меняются, но часто запрашиваются для вывода на сайт, то есть смысл хранить уже вычисленные значения, а не по 1000 раз в минуту заставлять бедный сервер пересчитывать одно и то же. Тем более, если сам расчет более-менее сложен и действительно нагружает сервер.

Цитата ("raznomir"):

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

ИХМО отчасти это верно. "повышает надежность и целостность БД" - это, конечно, вряд ли, а вот скорость и удобство использования может сильно увеличить.

Такой пример и личной практики.
Есть 2 связанных таблицы. Вторая хранит некие накапливаемые значания связанные с со строками первой таблицы. В первой таблице несколько сот тысяч записей, во второй по несколько сот записей для каждой строки из первой таблицы. При выводе данных в 99% случаев требуется только 1 последнее по дате значение из второй таблицы. Чем городить запросы и лопатить миллионы строк, проще последнее значение из второй таблицы продублировать в первой.

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

Цитата ("elosoft"):

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

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

Только одно НО. Вылет базы между двумя запросами приведет к тому, что во второй таблице добавится запись, а значение в первой не обновится. Поэтому этот метод повысит скорость, но надежность снизится.

Цитата ("Lisio"):

Только одно НО. Вылет базы между двумя запросами приведет к тому, что во второй таблице добавится запись, а значение в первой не обновится. Поэтому этот метод повысит скорость, но надежность снизится.

Кто б возражал. Я и написал соотвественно
Цитата ("elosoft"):

"повышает надежность и целостность БД" - это, конечно, вряд ли, а вот скорость и удобство использования может сильно увеличить.

Цитата ("Lisio"):

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

А вот это уже домыслы и клевета. Не надо переносить на других людей собственные паттерны.

Цитата ("Lisio"):

Только одно НО. Вылет базы между двумя запросами приведет к тому, что во второй таблице добавится запись, а значение в первой не обновится.

А вот не пишите кривые запросы, то и не будет такого.

Цитата ("Lisio"):

Структуру базы данных меняют только в редких случаях, а не когда захочется.

Официально запрещаю Вам менять структуру БД, когда Вам захочется :!:

Цитата ("raznomir"):

А вот это уже домыслы и клевета. Не надо переносить на других людей собственные паттерны.

Это решение было вами же и предложено, tvv про него уже писал.

Цитата ("raznomir"):

А вот не пишите кривые запросы, то и не будет такого.

Хм, ну предложите свой запрос, а то что-то и правда, болтовни много, а конкретики 0.

Цитата ("raznomir"):

Официально запрещаю Вам менять структуру БД, когда Вам захочется

Перечитайте свои же сообщения. Раздвоение личности?

Цитата ("raznomir"):

ИМЕННО!!!! Добавлять новую колонку, обычным sql-запросом, из обычного php-скрипта вызывая оный. Что этому мешает-то? То ли невозможность менять структуру БД в настольных программах, то ли что?

Это так, для напоминания, а то уже свои слова подзабывать начали.

Цитата ("elosoft"):

"повышает надежность и целостность БД" - это, конечно, вряд ли

А вылет обычного запроса на супер-целостной и супер-надежной БД не сделает ли бОльшей пакости, чем вылет запроса на БД с дублированно-излишними значениями? Как минимум, проверка "контрольной суммы" в случае нормализированной БД - это фикция, и Вы никак не сможете узнать, а то единственное значение в ячейке на самом деле верное, или глючное в результате каких-либо сбоев?
А Вы в курсе, что в системах с очень важными данными, если входные данные вносят операторы вручную, и есть риск обычной человеческой ошибки, то специально делается внесение одних и тех же данных двумя, а то и тремя операторами, и далее идет сравнение, одинаковое ли значение внесли все эти люди?
Тоже будете утверждать, что здесь избыточные и дублированные данные не повышают надежность системы и целостность данных?

Lisio, еще раз подчеркну: Вам нельзя менять. Вы же сами себе запретили.
Тем, кому это необходимо, - можно и нужно.

Цитата ("raznomir"):

А вылет обычного запроса на супер-целостной и супер-надежной БД не сделает ли бОльшей пакости, чем вылет запроса на БД с дублированно-излишними значениями?

Вы впадаете в крайности. Наверняка найдется такой, кто напишет 'drop table' с соответсвующими последствиями. К тому же ипользование БД и сохранение целостности и самих данных - это все же разные вещи. И решаются на разных уровнях.

Цитата ("elosoft"):

Вы впадаете в крайности

Не я начал...

Цитата ("elosoft"):

Наверняка найдется такой, кто напишет 'drop table' с соответсвующими последствиями.

Эммм... а Вы что, пользователям системы, пусть даже администраторам, даете возможность вот так напрямую запросы к БД писать????

Цитата ("elosoft"):

К тому же ипользование БД и сохранение целостности и самих данных - это все же разные вещи.

Ну и к чему это сказано?

Цитата ("raznomir"):

Вы что, пользователям системы, пусть даже администраторам, даете возможность вот так напрямую запросы к БД писать????

Нет, не даю. Но умельцев хватает. И что такое PhpMyAdmin знают даже те, кто не знает что такое поле.
Цитата ("raznomir"):

Цитата:

Цитата (elosoft):
К тому же ипользование БД и сохранение целостности и самих данных - это все же разные вещи.

Ну и к чему это сказано?

А вот к этому
Цитата ("raznomir"):

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

Цитата ("raznomir"):

Lisio, еще раз подчеркну: Вам нельзя менять. Вы же сами себе запретили.

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

Цитата ("elosoft"):

Нет, не даю. Но умельцев хватает. И что такое PhpMyAdmin знают даже те, кто не знает что такое поле.

Ну знаете, если человек уж залезает в PhpMyAdmin, то он преспокойно и не только drop table может сделать, а вообще что угодно, - и толку тогда с вашей целостности и неизбыточности БД будет?

Цитата ("raznomir"):

Ну знаете, если человек уж залезает в PhpMyAdmin, то он преспокойно и не только drop table может сделать, а вообще что угодно, - и толку тогда с вашей целостности и неизбыточности БД будет?

А для этого есть администратор сервера БД. И его обязанности такие случаи предусмотреть.