Моя любимая мозоль - «архитекторы», которые не понимают реляционных концепций и пытаются заставить вещи работать объектным способом, когда базы данных работают лучше на основе набора и должны быть разработаны для такого использования. (Базы данных не должны разрабатываться объектно-ориентированными программистами, ставшими архитекторами, они должны разрабатываться специалистами по базам данных) И архитекторами, которые считают более «элегантным» поместить несколько вещей в одну основную базовую таблицу (избыточная генерализация), а затем получить более 100 внешние ключи к этой таблице и каждому запросу, ссылающемуся на нее, и большой кошмар производительности (а также нелепый процесс удаления записи).

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

Java часто получает плохую прессу в этом отношении, и все более и более плохую прессу, поскольку воспринимаемая сложность Java EE увеличивается. Мой опыт работы с Java на фоне временного графика значительно упал после 2004 года, так что я не чувствую, что могу комментировать.

Мой последний опыт связан с тем, что архитектор отчаянно пытался точно представить объектную модель в наборе (реляционных) таблиц базы данных (например, Oracle). В результате получается схема базы данных, которую невозможно эффективно запросить без предварительного предварительного объединения нескольких таблиц (в материализованных представлениях).

Ответы на вопрос(11)

Ваш ответ на вопрос