SQLDBAКакой есть аналог Oracle APEX у MS для тех, кто хорошо знаком с SQL Server и слабо с разработкой клиентской части?
Цель - вести как минимум 80% разработки на строне БД.

А смысл? Каждый должен заниматься своим делом.

Аналогичный вопрос. Я вообще не бум-бум в базах данных, SQL для меня страшное слово и кошмары. Разрабатываю только HTML и JS. Что мне делать? Как и где хранить данные? Может смонстрячить свою СУБД на JavaScript? Нафига мне эти ваши SQL-и?

Короче бред.

Antonariyпонимаешь (вернее постарайся), большой объем ЛЮБЫХ операций с данными бд с точки зрения производительности выгодней выполнять в самой бд.

И зачем клиенту большой объём данных? Или, простите, для пейджинга нужно пилить монструозную процедурину на стороне SQL?

Как обычно, трещать в отрыве от реальной задачи (или хотябы её подобия), это всё равно что рассуждать о военной стратегии с инопланетянами, сидя на кухне.

Antonariyпонимаешь (вернее постарайся), большой объем ЛЮБЫХ операций с данными бд с точки зрения производительности выгодней выполнять в самой бд.

Наверное это мало кто понимают, ибо до сих пор успешно пилят серверные приложения. Вот дебилы.

AntonariyСовершенно верно, они дебилы, поскольку не понимают, для чего это делают и почему успешно. Переносимость, масштабируемость, все это маркетинговая шелуха для продуктов типа 1с.

Да что ты? Переносимость и масшабируемость оказывается не нужна? Мужики-то не знали

AntonariyБольше продаж — больше успех — больше бухла на корпоративах — более доступны бухгалтерши. Жизнь удалась!

А ты хочешь, чтобы жизнь не удавалась? Давай не ровняй всех под себя.

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

Ни а чом.

AntonariyОднако количество таких систем можно пересчитать по пальцам.

Давай посчитаем, пожалуйста. Пальцев 10. Ждём-с.

AntonariyПодавляющее число разработчиков разрабатывает системы внутренние или под конкретный заказ, а не универсальную коробку. Тип хранилища при этом фиксируется еще на этапе согласования ТЗ сообразно задачам/бюджету.

Это так. Но никто не застрахован. Не буду выдумывать, скажу из реального опыта. Есть система, работала под MS SQL. Заказчик попросил перевести её на Postgres. Почему? Потому что он захотел сосредоточить свой бюджет на разработке, а не на лицензиях. Ну не подрасчитал малость, а со своими запросами расставаться не захотел. И что? Мы перенесли, за достаточно небольшой срок и не сильно большими усилиями. Если бы там было куча гавнища на T-SQL/PL-SQL, мы бы конкретно заеплись, а ещё и специалистов надо было искать, узкоспециализированных. Вот и нах нам такое надо? Или клиенту?

Так что не чеши тут по ушам.

AntonariyНе пользоваться при этом возможностями хранилища, которые повышают производительность системы, это просто непрофессионализм, школотронство (исключая случаи, когда допиливается уже имеющийся аналог адинэски).

Пользоваться надо при реальной необходимости, я уже об этом сказал, а ты многозначительно пофыркал (что выдаёт твоё сплошное дилетанство).

AntonariyЕсли в ТЗ будет пункт "а вдруг мы захотим сменить тип хранилища", то это верный признак того, что заказчик упорот.

И что с того? Если заказчик не написал в ТЗ «пишите код хорошо, придерживайтесь стиля, не говнокодьте пожалуйста», то всё можно чтоли? Можно говнить? Не тупи.

AntonariyИли его развели всякие там хвосты, навешав маркетинговой лапши из ритейл-кухни под соусом из разных страшных технических слов.

Ни а чом. Как обычно, всё что пока вижу, это жидкие набросы и инопланетянские, оторванные от реальности, домыслы. Речь не мужа, а сопливого дитя. По фактажу ноль.