Чуть сложнее, чем стандартная Entity-Attribute-Value модель. Сам подобным «грешил» в проекте, представляющим собой набор произвольных справочников. подтверждаю, что разработка бизнес-логики с таким подходом упрощается, кода совсем немного получается, и он слабо связан. Хочу заметить, что для аналитики этих данных их лучше денормализовать (мы сбрасывали денормализованные данные в MongoDB).
Круто, чо.
Я вот не понимаю споров о том, что все надо делать на JS, или не делать на JS. Делайте как хотите, браузеры Вам это позволяют. Здесь лишь пример того, как то же самое можно сделать по другому.
Очень важно, на мой взгляд, особенно в начале, тщательно контролировать качество кода на выходе.
Необходимо избежать механического дробления кода на, удовлетворяющие правилам, куски.
Поделитесь опытом, как это контролировать в команде из десятка программистов в стадии активной разработки продукта?
И еще такой вопрос, как убедить команду, что это верный подход?
Про разворачивание приложение в публичном облаке OpenShift куча статей, а вот про разворачивание всего этого чуда на своем сервере информации немного. Я пробовал по инструкции от digitalcloud. И оно даже работало, но многое пришлось додумывать, дописывать, догугливать. Может поделитесь своим опытом в этом вопросе?
Согласен, вероятность этого не велика. Просто я все чаще слышу от менеджеров вопросы, по типу «а можем наше приложение не на Oracle поставить?». А связан такой вопрос со стоимостью лицензии на СУБД от Oracle. Т.е. приложение, допустим, стоит 500 килорублей в базовой комплектации, но для его работы нужно прикупить лицензию на СУБД еще за 500 килорублей. И на фоне этого привлекательность Вашего приложения по цене уже не такая, как заявлено в рекламе. А проект Ваш с многолетней историей (читай legacy), львиная доля бизнес логики лежит в СУБД. И Вы как разработчик вынуждены сообщить менеджеру, что это не реально сделать даже за год. Соответственно, ни а каком перезапуске проекта речи не идет. Но и Вы, как компания, начинаете терять конкурентные преимущества.
Было бы интересно узнать, какая серьезная причина может привести к смене СУБД посреди проекта.
Посреди проекта сменить СУБД может заставить банально очередной Федеральный Закон, запрещающий использовать зарубежное ПО, если есть отечественный аналог в реестре отечественного ПО. А софт Ваш, например документооборот, и бюджетные или государственные учреждения Ваш целевой клиент. А не будь бизнес логики в БД, глядишь и за пару месяцев можно поддержать работу приложения на другой СУБД, отличной от Oracle.
Из всего этого, у меня нарисовалась другая картинка: Вы разрабатываете приложение, которое может в качестве СУБД использовать Oracle, PostgreSQL и MSSQL Server. Как Jira, например, делает. Тогда Вам уже нужно поддерживать бизнес логику во всех поддерживаемых СУБД? Как с этим быть?
Полностью согласен с утверждениями Тома Кайта о том, что восприятие СУБД как сложного черного ящика есть абсолютное зло. Но реальность заключается в том, что именно с такими разработчиками чаще всего приходится иметь дело. И приходится тратить время на то, чтобы научить разработчика мыслить иначе.
Я ни в коем случае не пытаюсь оградить разработчиков от СУБД, наоборот, я, при любом удобном случае, пытаюсь «окунуть с головой» разработчика в Oracle. И считаю, что хороший разработчик должен быть хорош во всем, и в СУБД, и во фреймворках, используемых на проекте, и в предметной области, в которой работает приложение. По сему, пойду изучать Oracle по приведенным ссылкам, еще раз спасибо.
Бизнес логика в БД это конечно круто, но как быть с программистами, которые приходят в команду и не то что с MySQL, а просто с SQL на «вы»? Зато джавист он добротный, например. Не брать такого парня?
Плюс, как правило, этой логикой владеет только тот, кто ее реализовал. И, как выше написали, никому не рассказывает что это за логика, и почему именно так написана.
А как быть с тестированием этой логики? Есть какие-то инструменты для unit-тестирования Ваших процедур и функций? А что если придется менять СУБД? В общем, больше вопросов, чем ответов. По сему, я сомневаюсь, что реализация бизнес логики на уровне хранимых процедур в БД — это хорошая идея.
Не рассматривали Dojo 2? Ну так, в качестве альтернативы? Просто мы используем Dojo около 2х лет, и проблем с пониманием его верстальщиками, программистами, дизайнерами не наблюдалось. Да он не поворотлив в основе, но для «жирного ынтерпрайза» вполне заходит. В основном из-за своего представления ООП в JS. Оно сразу понятно backend разработчикам. Правда если ты, в принципе, не знаком с JS будь готов выстрелить себе в ногу из-за не понимания того, что никакого ООП в JS нет.
По поводу выяснения потребностей полностью согласен. Ко мне постоянно приходят менеджеры и задают один и тот же вопрос «Сколько стоит это сделать?», на что я задаю встречный вопрос «Зачем это заказчику?». Они уходят спрашивать, выяснять. Таким простым вопросом удалось повысить качество аналитики задач перед тем, как они пойдут в разработку.
Идея не плоха, но идея без реализации ничего не стоит. Вот если бы Вы привели живой пример такой схемы, можно было бы оценить такой подход. А так… Извините, нет.
Я вот не понимаю споров о том, что все надо делать на JS, или не делать на JS. Делайте как хотите, браузеры Вам это позволяют. Здесь лишь пример того, как то же самое можно сделать по другому.
Поделитесь опытом, как это контролировать в команде из десятка программистов в стадии активной разработки продукта?
И еще такой вопрос, как убедить команду, что это верный подход?
Посреди проекта сменить СУБД может заставить банально очередной Федеральный Закон, запрещающий использовать зарубежное ПО, если есть отечественный аналог в реестре отечественного ПО. А софт Ваш, например документооборот, и бюджетные или государственные учреждения Ваш целевой клиент. А не будь бизнес логики в БД, глядишь и за пару месяцев можно поддержать работу приложения на другой СУБД, отличной от Oracle.
Из всего этого, у меня нарисовалась другая картинка: Вы разрабатываете приложение, которое может в качестве СУБД использовать Oracle, PostgreSQL и MSSQL Server. Как Jira, например, делает. Тогда Вам уже нужно поддерживать бизнес логику во всех поддерживаемых СУБД? Как с этим быть?
Полностью согласен с утверждениями Тома Кайта о том, что восприятие СУБД как сложного черного ящика есть абсолютное зло. Но реальность заключается в том, что именно с такими разработчиками чаще всего приходится иметь дело. И приходится тратить время на то, чтобы научить разработчика мыслить иначе.
Я ни в коем случае не пытаюсь оградить разработчиков от СУБД, наоборот, я, при любом удобном случае, пытаюсь «окунуть с головой» разработчика в Oracle. И считаю, что хороший разработчик должен быть хорош во всем, и в СУБД, и во фреймворках, используемых на проекте, и в предметной области, в которой работает приложение. По сему, пойду изучать Oracle по приведенным ссылкам, еще раз спасибо.
Плюс, как правило, этой логикой владеет только тот, кто ее реализовал. И, как выше написали, никому не рассказывает что это за логика, и почему именно так написана.
А как быть с тестированием этой логики? Есть какие-то инструменты для unit-тестирования Ваших процедур и функций? А что если придется менять СУБД? В общем, больше вопросов, чем ответов. По сему, я сомневаюсь, что реализация бизнес логики на уровне хранимых процедур в БД — это хорошая идея.