Илья Ермаков писал(а):
Если позволите, краткое резюме. Автор, по сути дела, говорит о том, что очень плохо, когда за проект берутся дилетанты. Но это справедливо для любых проектов, безотносительно клиент-серверных технологий.
Вздохи автора по поводу того, что раньше было... не слишком обоснованы. Раньше, в основном, были отдельные АРМы (автоматизированные рабочие места), сейчас, как правило, речь идет о более комплексных проектах. Мало кому нужен АРМ бухгалтера или инспектора отдела кадров, нужна бухгалтерия и отдел кадров, желательно интегрированные с другими подсистемами. Ну, а сравнивать АРМ с подсистемой некорректно, прежде всего, с идеологической точки зрения.
Однако не это в статье самое неприятное... Сам автор допускает довольно много ляпов... Вот, например,
Цитата:
На самом деле есть еще такая вещь, как View, - это тот же запрос, но подготовленный средствами SQL-сервера. Из клиентских программ с ним можно работать почти как с таблицей, но редактировать, естественно, нельзя...
SQL-сервер не готовит View, View - это запрос сохраненный на сервере. View могут быть изменяемые (редактируемые) и не изменяемые (не редактируемые) (см. стандарт SQL-92).
Цитата:
К пониманию необходимости динамического порождения SQL-запросов рано или поздно приходят все разработчики, кроме разработчиков базового инструментария. Видимо, им самим не приходится пользоваться своими творениями.
Динамическое порождение запросов, в общем случае, не является необходимым. Для подавляющего количества применений вполне достаточно стандартной (то есть, принятой стандартами SQL, начиная с SQL-92) параметризации запросов. Это относится и к запросам на выборку, и к запросам на изменение (добавление, удаление, редактирование). Реально, динамические запросы необходимы в случае, если происходит модификация схемы базы данных (модификация метаданных) из приложения, что, само по себе, является нонсенсом в большинстве задач.
Цитата:
Вообще говоря, многопользовательские приложения - это частный случай многозадачности. А многозадачность, как известно, влечет одну фундаментальную проблему: многозадачные приложения практически невозможно отлаживать, поскольку смоделировать все многообразие вариантов взаимодействий асинхронно работающих процессов крайне сложно.
Многозадачность, строго говоря, может быть разной... Работа с БД относится к многозадачности над одним набором данных, но и этот класс многозадачности ограничен конечной сериализуемостью, когда, не взирая на внешний параллелизм, обработка данных выполняется строго последовательно. Такие задачи допускают достаточно простую отладку, хотя она, конечно, отличается от отладки однозадачного приложения.
Цитата:
Оптимистическая стратегия исходит из того, что мы пытаемся выполнить операцию и уже в момент закрытия транзакции узнаем, что кто-то поменял наши данные до нас. После чего повторяем попытку.
Повторение попытки в рамках той же транзакции не имеет ни малейшего смысла. Транзакцию необходимо перезапустить.
Цитата:
Длинные отчеты, не меняющие данные, но привязанные к определенному моменту времени, также нужно защищать. Если мы хотим получить состояние склада на 14:00, а соответствующий отчет генерируется полчаса, то за это время в систему введут еще десяток проводок, и мы получим отчет, не соответствующий никакому моменту времени.
Для этого существует высокие уровни изолированности, в частности, REPEATABLE READ и SERIALIZABLE. Если необходимо обеспечить доступность данных, в том числе и для изменения, при работающих транзакциях с высокими уровнями изолированности, необходимо применять версионные СУБД, которые позволяют сосуществовать/работать "пишущим" и "читающим" транзакциям. И т.д.
В целом, статья не оставляет положительного впечатления.
Вход
FAQ
Поиск
