Запланируйте, пожалуйста, падение сервера со всеми исходниками без единой возможности восстановления (плохой сисадмин, три землетрясения, инопланетяне — плевать; договоры и дедлайны, естественно, при этом никуда не делись), смену генерального директора (и концепции работы организации вместе с увольнениями, сменой новеньких Маков на древние XT и построениями в пять утра), внезапный перелом всех конечностей пьяным бомжом и войну с Китаем. Напоминаю, слова «внезапно», «форс-мажор» или «не- или маловероятно, не рассматриваю» — это неумение планировать (разве вы не верите в инопланетян?).
Если серьезно — есть вещи, которые вы так или иначе упустите в планировании (хотя бы потому, что вы человек, обладаете субъективным восприятием и не знаете всего-всего на свете), и они будут как раз «внезапно» (вы же не знаете, когда и что именно наступит, и как именно вы отреагируете — вы можете лишь костяк реакций накидать и оставить запас ресурсов, но будут ли абстрактные реакции соответствовать проблеме, и хватит ли отложенных ресурсов?). Или я как-то не так понял ваш категорический ответ «отсутствие внезапностей — это умение планировать»?
Не знаю, как остальные люди «со стойким характером и железной волей», в которые, судя по всему, заочно меня записали, а я стараюсь придерживаться мысли «это не меня заставили, а я согласился» (в стиле «в армии нет слова „потерялось“ — есть слово „проебал“»). Я не говорил, что никогда-никогда не пойду на преступление — я призывал думать, что это даст (как плюсы — просто так же преступления не совершаются, так и минусы вроде тюремного заключения), а вся эта ветка комментариев началась из-за слова «заставить», а не из-за морально-этических принципов.
… Это так «демократично» и так по американски заставить честных людей пойти на преступление …
Простите, а где вы увидели «заставить»? Если ко мне подойдет левый парень и начнет канючить «ну убей человека, ну купи наркотики, ну ограбь бабушку», а я соглашусь, то это ССЗБ и никак иначе. Втерлись в доверие и подтолкнули к преступлению? Меньше доверяй людям и думай собственной головой о последствиях.
По-хорошему должны именно учить, но путь «создать ситуацию, в которой тебе придется научиться, а иначе ты проиграешь» тоже имеет право на существование. Он сложнее, жесче, результаты не поддаются настолько гибкой корректировке, как с ведущим тебя педагогом-учителем, но все же приводит к успеху. С другой стороны, на последних курсах просто нельзя по-другому — не будет же всю жизнь тебя учитель за ручку вести, и поэтому нужно научиться справляться с проблемами (искать материал и делать выводы) самостоятельно. Здесь более чем справедлива фраза «учитель учит (обучает, помогает), преподаватель преподает (дает, читает) материал».
Если только как «миграции не рассматривались в рамках темы данного поста». Выбор места для бизнес-логики — всего лишь одна из кучи архитектурных задач, и работать им все равно придется в тандеме.
Не поддерживали вы студенческие недоделки, ой не поддерживали… Вы бы не только разные БД в одной системе увидели. Хотя я имел в виду «одну систему написать с использованием SQL Server, другую на Оракле, третью на MySQL, четвертую на SQLite, PostgreSQL...» — повторюсь, есть разные заказчики и разные требования, и иногда слова «тут неуместна SQL Server, и мне все равно, что вы пять лет назад купили лицензию, и поэтому должны ее отработать» могут стоить проекта тысяч на 500. Впрочем, против такого идеализма я ничего не имею.
Ускорение разработки? Это вы про то, что разработчику приходится переключаться между языком высокого уровня и процедурами SQL, разнящимися от базы к базе? Или про то, что ценой этапа синхронизации модулей программы из разных сред (Java и Oracle DB разные же среды, не так ли?), который, опять же, стоит дороже синхронизации модулей из одной среды (проще отладить два куска Java, чем Java и интерпретатор запросов/процедур SQL-базы), можно распараллелить разработку (интересно, что мешает двум разработчикам писать на одном языке)?
Кстати, вы с таким подходом с миграциями и версионностью разрабатываемых систем работали? Миграция таблиц и данных в них — уже целое приключение, а хранимые процедуры и сложные вьюхи…
Никто не говорил об альтернативах — я просто уточнял вашу идею (^_-) И, кстати, даже с точки зрения «база данных только для CRUD» оно не кажется из ряда вон выходящим (ИМХО, конечно). Хотя, на мой взгляд, CONCAT(' (', c.TemperatureAir, ' °C)') — ерунда, потому что отображение около числа надписи "°C" или «в градусах Цельсия» (и уж тем более заключение значения в скобки) — задача только представления и ничья больше. Даже бизнес-логика оперирует данными, такими, как «5» или «значение в градусах Цельсия» (последнее скорее как абстрактная идея, значение enum, отвечающего за шкалу, нежели как конкретное высказывание).
Кстати, плата за «размытие логики» = оплата разработчикам лишних трудовых часов, необходимых для «вспоминания» архитектуры и всех нюансов, сделанных ради скорости работы всей системы. Вопросы, обозначенные в посте, обычно поднимаются на крупных проектах, с которыми работают весьма объемные команды с неплохой почасовой ставкой (не наши детсадовские 1000-2000$). Да, опыта и личных качеств им не занимать (иначе бы не платили), но все-таки это люди, и им нужно входить в контекст, в поток. Сравнима ли стоимость подобных оптимизаций с точки зрения оплаты труда (это я еще не считаю другие расходы) со стоимостью медленной работы конечной системы? Или вы всю жизнь занимались разработкой биржевых экономических систем и игровых движков, где скорость работы крайне критична?
Вы так и не ответили на вопрос, как вы тянете результаты работы бизнес-логики из базы данных.
Ситуация: есть некий интернет-магазин. В нем есть товары. У товаров, как ни странно, есть цены.
Во-первых, эти цены бывают в разных валютах — нужно знать текущие курсы и уметь их пересчитывать (как для отображения в каталоге, так и для расчета суммы заказа).
Во-вторых, существуют скидки на определенные группы товаров — их также нужно отображать в каталоге и учитывать при суммировании. Скидки, кстати, бывают не только "-20%", но и «купи две — третья бесплатно». Уже хорошо как для алгоритма, так и для администратора интернет-магазина (он не полный идиот и не будет переписывать каждый раз сложные процедуры — он настроит скидки в админке, а система сгенерирует SQL для процедуры сама).
В-третьих, бывают хитрые условия доставки и оплаты a-la «доставка от 2500 рублей бесплатна, но при доставке за МКАД оплачивается каждый километр; также учитывается вес заказа, подъем на этаж и фаза луны».
В-четвертых, бывает, что налоги рассчитываются из разных «точек» — от суммы цен товаров, от суммы цен товаров с учетом скидок, от суммы заказа с учетом предыдущих налогов...
Самое прикольное (в моем списке) — в-пятых: товары могут иметь различные настраиваемые параметры, от которых также может зависеть их цена (цвет, комплектация etc). Весело, не так ли?
И все бы хорошо, и иногда действительно нужно запихнуть бизнес-логику в базу данных — например, без пересчетов валют и скидок не будет работать сортировка товаров по цене. Однако как из описанной мною выше ситуации из базы данных вытянуть информацию о заказе, которая должна включать в себя все товары, их обычные цены, цены со скидками (мы любим рисовать зачеркнутые цены), выбранные параметры товаров (их может быть сколько угодно — хоть ноль, хоть один, хоть 30), выбранные способы доставки/оплаты, все промежуточные точки расчета групповых скидок, налогов и итоговую сумму? Результат запроса-то у нас двухмерный. Будете городить стремные конструкции из диких JOIN и UNION, чтобы все уместить в одно отношение, или же разобьете запрос на несколько маленьких, и они будут дублировать части друг друга (например, отдельно список товаров и их параметры, отдельно сумма этого же списка + скидки/налоги + итог)?
Вы ведь уже использовали описанную форму «в бою»? Скажите, насколько эффективно используется поле «Заголовок»? Заполняют ли его вообще, заполняют ли по делу или пишут чушь… И заодно про распределение по категориям (список «Поместить в») — как часто приходится перебрасывать обращения (пусть даже сугубо виртуально a-la «это не идея, блин, это сообщение об ошибке»)?
1. Может, я что-то упустил, но как вы в итоге получаете конечную объектную модель для ее отображения, если БД, насколько я помню, в большинстве своем умеют отдавать только одно- и двухмерные данные? Скажем, та же сводная страница покупателя, на которой нужны ФИО, адрес, список его заказов с подробным перечнем товаров, пересчетами валют и скидками, использованные купоны… Фантазия заказчика, к сожалению, безгранична. Вы их как-то упаковываете в таблицы или достаете кучей разных запросов, а потом сшиваете в клиенте/middleware? Не было ситуаций, когда для «сшивки» данных все равно требовались какие-то бизнес-правила? Хотя ими тоже можно напрячь базу данных… Но тогда не возникнет ли противоречие вашей стратегии оптимизации (не использовать второй слой для того, что умеет сама БД), ибо базе придется либо формировать сложные результирующие данные, либо кешировать промежуточные запросы (если вы получаете данные несколькими заходами-процедурами), либо таки дублировать их.
2. ИМХО, бизнес-логику выносят в отдельный слой (tier, если угодно) с идеей упрощения архитектуры — «БД умеет только CRUD и больше ничего, клиент умеет только получать и дооформлять данные (например, через XSLT — особо тяжелых вычислений на клиенте быть не должно), а также формировать запросы, а центральный сервер умеет только парсить запросы клиента, дергать БД, что-то вычислять и формировать конечный отклик». Те же сортировки-группировки-курсоры можно считать частью бизнес-логики, лежащей на центральном сервере, а БД воспринимать исключительно как интерпретатор сложных запросов, а не как самостоятельный «мозговой центр» (по сути, между «дай мне всю таблицу» и «по хитрожопому отJOINь десять таблиц и прогруппируй по двадцати столбцам в случайном порядке» никакой разницы — что БД сказали делать, то она и сделает без особой инициативы).
К SSH еще подключиться надо, а порт прокси можно просто ограничить локальными подключениями (не уверен насчет возможностей самого SSH-клиента, но есть же файерволы etc).
Если серьезно — есть вещи, которые вы так или иначе упустите в планировании (хотя бы потому, что вы человек, обладаете субъективным восприятием и не знаете всего-всего на свете), и они будут как раз «внезапно» (вы же не знаете, когда и что именно наступит, и как именно вы отреагируете — вы можете лишь костяк реакций накидать и оставить запас ресурсов, но будут ли абстрактные реакции соответствовать проблеме, и хватит ли отложенных ресурсов?). Или я как-то не так понял ваш категорический ответ «отсутствие внезапностей — это умение планировать»?
Простите, а где вы увидели «заставить»? Если ко мне подойдет левый парень и начнет канючить «ну убей человека, ну купи наркотики, ну ограбь бабушку», а я соглашусь, то это ССЗБ и никак иначе. Втерлись в доверие и подтолкнули к преступлению? Меньше доверяй людям и думай собственной головой о последствиях.
Думаю, анекдот — то, что для «превращения GRUB 2.0 в BURG» (на деле — просто имитация эффекта) нужно поменять всего один символ в исходниках.
Кстати, вы с таким подходом с миграциями и версионностью разрабатываемых систем работали? Миграция таблиц и данных в них — уже целое приключение, а хранимые процедуры и сложные вьюхи…
CONCAT(' (', c.TemperatureAir, ' °C)')— ерунда, потому что отображение около числа надписи "°C" или «в градусах Цельсия» (и уж тем более заключение значения в скобки) — задача только представления и ничья больше. Даже бизнес-логика оперирует данными, такими, как «5» или «значение в градусах Цельсия» (последнее скорее как абстрактная идея, значение enum, отвечающего за шкалу, нежели как конкретное высказывание).Ситуация: есть некий интернет-магазин. В нем есть товары. У товаров, как ни странно, есть цены.
И все бы хорошо, и иногда действительно нужно запихнуть бизнес-логику в базу данных — например, без пересчетов валют и скидок не будет работать сортировка товаров по цене. Однако как из описанной мною выше ситуации из базы данных вытянуть информацию о заказе, которая должна включать в себя все товары, их обычные цены, цены со скидками (мы любим рисовать зачеркнутые цены), выбранные параметры товаров (их может быть сколько угодно — хоть ноль, хоть один, хоть 30), выбранные способы доставки/оплаты, все промежуточные точки расчета групповых скидок, налогов и итоговую сумму? Результат запроса-то у нас двухмерный. Будете городить стремные конструкции из диких JOIN и UNION, чтобы все уместить в одно отношение, или же разобьете запрос на несколько маленьких, и они будут дублировать части друг друга (например, отдельно список товаров и их параметры, отдельно сумма этого же списка + скидки/налоги + итог)?
2. ИМХО, бизнес-логику выносят в отдельный слой (tier, если угодно) с идеей упрощения архитектуры — «БД умеет только CRUD и больше ничего, клиент умеет только получать и дооформлять данные (например, через XSLT — особо тяжелых вычислений на клиенте быть не должно), а также формировать запросы, а центральный сервер умеет только парсить запросы клиента, дергать БД, что-то вычислять и формировать конечный отклик». Те же сортировки-группировки-курсоры можно считать частью бизнес-логики, лежащей на центральном сервере, а БД воспринимать исключительно как интерпретатор сложных запросов, а не как самостоятельный «мозговой центр» (по сути, между «дай мне всю таблицу» и «по хитрожопому отJOINь десять таблиц и прогруппируй по двадцати столбцам в случайном порядке» никакой разницы — что БД сказали делать, то она и сделает без особой инициативы).