Практика показывает, что зачастую это связанные вещи. Ну, то есть одно дело пара опечаток, другое — общая неграмотность. Ну и, конечно, мы же все-таки на сайте в зоне.ру.
Ну ведь я о том и говорю. Если бы все работало изначально как планировали, то большинства проблем не было бы, так? И менеджеры бы не были нужны, ведь и так все ок.
Понятно, но сравнение все же не совсем адекватное. Поймите, тут рынок меньше, количество сделок тоже меньше. Вот, например, если вы купите решение от Amdocs, то да, тут все как вы описали. Только имейте в виду, что это уровень большой тройки. Тут речь идет про самописные наколеночные решения, наколеночных хардов не делают :)
Боже, вы о чем вообще? Хотите, чтобы какой-то хрен с горы диктовал вам условия? Отношения между компаниями носят как правило деловой характер (репутация и прочее). Отношения с сумрачными гениями могут быть какими угодно, я говорю по опыту. Ставить бизнес в зависимость от прихотей разработчика — ставить компанию под угрозу, потому что ему может в любой момент придти в голову что угодно (например, копье). В зависимости от того кто и как оценивает эти риски, так и принимается решение об отказе от идеально заточенной системы в пользу более универсального решения. Чем крупнее оператор, тем более вероятно, что эти риски он уже оценил и выбрал коробку.
Зачастую авторы самописных решений держат контору за яйца. Это, конечно, не сразу происходит, со временем, но не удивительно, что бизнесу такая ситуация не нравится. Bus factor у одного-двух сумрачных гениев все-таки куда выше, чем у конторы, которая уже много лет работает на рынке.
«Вкратце этот дизайн иногда встречается.»
«Использование многоточие для получения всех элементов, является нарушением принципа „Только Один Путь Достижения Цели“.»
«Хотя в какой то момент оно идет слишком далеко.»
Ад.
Мой опыт показывает, что от SQL еще никто не умер. Неплохо, конечно, поручать работу Arel и руби вообще, но иногда массовые операции проще проводить через SQL. В первую очередь это касается DDL, потому что с выборками как правило можно извернуться достаточно элегантно.
Я считаю, что некорректно использовать схему БД для «микро-оптимизации». Наличие констрейнтов должно целиком и полностью определяться бизнес-логикой. Констрейнты нужны для исключения невозможных данных, когда в алгоритмах возможны ошибки. Также они несут смысловую нагрузку, отражая часть архитектуры приложения.
В оракле по данным с педивикии работает 108 тысяч человек. Между 10-м и 11-м релизом четыре года разницы. Я не пытаюсь что-то доказать или опровергнуть, но видно, что при таких условиях это может быть правдой.
Такой подход удлинняет цепочку наследования и фактически может увеличить время поиска метода при его вызове. Но не думаю, что сколько-нибудь существенно.
«Использование многоточие для получения всех элементов, является нарушением принципа „Только Один Путь Достижения Цели“.»
«Хотя в какой то момент оно идет слишком далеко.»
Ад.
Да, на автобусах и метро не езжу.
en.wikipedia.org/wiki/Oracle_Corporation
en.wikipedia.org/wiki/Google