А не проще было бы приоритет ниже среднего установить для процесса «специализированного программного обеспечения, позволяющего производить сетевые расчеты» или там же, в менеджере задач, указать конкретные ядра, которые оно может использовать?
Я рад за вас. Среди «кучи возможностей» лично я хотел бы воспользоваться самой цивилизованной — купить непосредственно у Гугла. К сожалению, в Украине сделать этого я не могу. Поэтому мне не понятна радость от выпуска украинского Ютуба. Я даже не замечаю, каким именно Ютубом пользуюсь, украинским, французским или американским, это не стоит ни копейки. А вот отсутствие возможности купить вещь я замечаю, и заметность эта равна, как вы правильно сказали, сотне долларов.
Первый вариант — на pl/sql, [почти] двухзвенная архитектура, где клиент знает только названия и параметры хр. процедур, реализующих бизнес-логику, а внутри процедур уже идут выборки, журналирования, проверки прав доступа и т.п.
Второй вариант — на .net, трехзвенная архитектура, когда всю логику реализует сервер приложений, написанный на C#. В этом варианте от БД требуется только insert/update/delete.
Я понял, мы рассматриваем разные типы продуктов. Вы говорите о коробочных вариантах, неких универсальных решениях, готовых «работать» где и с чем угодно, а я имею ввиду штучные системы под конкретных заказчиков. В первом случае интеграторы пытаются натянуть бизнес клиента на имеющийся глобус, во втором — изобретается велосипед под конкретные нужды бизнеса. Так вот в вариантах с «говнософтом», как вы изволили выразиться, тип БД определяется заранее.
Вы часто встречали серьезные системы, в которых заранее не известна база данных? Простая логика говорит, что стараясь подстроится под всех, вы не сможете воспользоваться плюшками ни одной. Поэтому еще на начале проектирования выбирается конкретная СУБД и дальше пляшут от нее. За 12 лет работы я только однажды участвовал в проекте, где по требованиям нужно было сделать поддержку трех различных БД. Во всех остальных случаях база была известна заранее, что позволяло использовать преимущества именно ее.
Теперь про геморойность. А кто сказал, что создание систем — это легко? Да, нужно руками делать вещи, которые в каких-нибудь фреймворках уже готовы. И не факт, что сделанное самостоятельно будет хуже черного ящика, в работоспособность которого веришь со слов индуса. Конечно, это сложнее и ответственности больше. Ну дык и заплатят за систему, обсчитывающую десятки сущностей в секунду против десятков секунд на одну сущность у индусов, гораздо больше :)
PS. Не думайте, что фреймворки и шаблоны — это панацея от всех бед. К сожалению, многие утрачивают здравый смысл в погоне за «правильностью»…
Не понял, что не так? Если вы знаете, что в Оракле есть механизмы, то к чему тогда вопросы? То, что нужно написать свою реализацию отправки письма, использующую оракловый пакет, а не воспользоваться готовым фреймворком? Ну да, нужно сделать лишнее ручное движение. Зато скорость работы перекрывает все подобные издержки. Что не так с тестированием? Берете и покрываете тест-кейсами все, что захотите. Какая разница? И да, результаты тестирования можно присылать по СМС-ке, только у нас из-за бесплатности используемого механизма была задержка в 7 мин. Повторюсь еще раз: где во главу угла ставится скорость работы, там большинство фреймворков и шаблонов проектирования идут лесом! Никто не будет оценивать красоту вашей архитектуры и легкость реализации, если система не работает (а медленно работающая считается не работающей!).
Ваши слова основываются на реальном опыте? Мне довелось участвовать в разработке одной и той же системы, один вариант которой был реализован на pl/sql, второй — на .net. Так вод логика внутри БД оказалась на порядок быстрее при том, что данных было тоже на порядок больше (на всякий случай уточню: реализовывали биллинговую систему). При этом на привязку к Ораклу было глубоко всем наплевать, ибо переходить ни на что другое даже в мыслях не было, а по масштабированию… база не напрягаясь делала то, на что у дотНета в тестовом прогоне уже не хватало памяти :)
Согласен со второй половиной определения — «с целью повышения количества продаж и максимизации прибыли», а вот в первой части слова «процесс выявления» я бы заменил на «процесс навязывания, обмана». Язык не поворачивается назвать маркетинг конструктивным, это абсолютно деструктивное явление, наравне с патентным троллингом, активизировавшимся в последние годы.
Ну дык «юридические препятствия» — это же не объективная инженерная проблема, это маркетинговое «непозвалям», призванное разводить потребителей на деньги.
Не рассказывайте об этом начальству, а то оно сломает вам ногу!
Первый вариант — на pl/sql, [почти] двухзвенная архитектура, где клиент знает только названия и параметры хр. процедур, реализующих бизнес-логику, а внутри процедур уже идут выборки, журналирования, проверки прав доступа и т.п.
Второй вариант — на .net, трехзвенная архитектура, когда всю логику реализует сервер приложений, написанный на C#. В этом варианте от БД требуется только insert/update/delete.
Теперь про геморойность. А кто сказал, что создание систем — это легко? Да, нужно руками делать вещи, которые в каких-нибудь фреймворках уже готовы. И не факт, что сделанное самостоятельно будет хуже черного ящика, в работоспособность которого веришь со слов индуса. Конечно, это сложнее и ответственности больше. Ну дык и заплатят за систему, обсчитывающую десятки сущностей в секунду против десятков секунд на одну сущность у индусов, гораздо больше :)
PS. Не думайте, что фреймворки и шаблоны — это панацея от всех бед. К сожалению, многие утрачивают здравый смысл в погоне за «правильностью»…