Petro123,

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

То есть Вы считаете, что человек может порекомендовать удачное решение и архитектуру в незнакомой сфере, даже не зная какие проблемы могут скрываться на этом пути?

Как вообще можно управлять сложными структурами данных инструментом, который не объектно ориентирован? Разумеется это возможно, но вот насколько удобно и правильно - совсем иной вопрос!
Хранимые процедуры в SQL придумывались не для того, что бы на них бизнес логику реализовать. Они придумывались для того, что бы данные к нужному формату приводить (например в зависимости от региона или назначения вводить/выводить даты в разных форматах: dd.mm.yyyy, mm/dd/yyyy, dd.mm и т.д.) :) Ну и разумеется для упрощения сложных запросов.

вадяавторТо есть Вы считаете, что человек может порекомендовать удачное решение и архитектуру в незнакомой сфере, даже не зная какие проблемы могут скрываться на этом пути?
я не рекомендую в сфере php, просто высказывания из практики.
авторКак вообще можно управлять сложными структурами данных инструментом, который не объектно ориентирован? Разумеется это возможно, но вот насколько удобно и правильно - совсем иной вопрос!
Хранимые процедуры в SQL придумывались не для того, что бы на них бизнес логику реализовать. Они придумывались для того, что бы данные к нужному формату приводить (например в зависимости от региона или назначения вводить/выводить даты в разных форматах: dd.mm.yyyy, mm/dd/yyyy, dd.mm и т.д.) :) Ну и разумеется для упрощения сложных запросов.
ты такое в в ветке mssql не пиши, чтоб нам не пришлось некрологи сочинять

Вы же понимаете, что для выбора какой инструмент лучше, надо знать и тот и другой в достаточной мере.
Я могу сказать, что знаю SQL в достаточной мере, что бы не писать на нём бизнес-логику. И знаю в достаточной мере php, что бы не пытаться на нём велосипедить и реализовать хранение большого объёма данных. Также я не стал бы сложное серверное приложение реализовывать на js. И не пытался бы реализовывать вэб приложение на паскале (а не смотря на то, что делфи "из коробки" умеет работать с http, и на нём тоже этого писать не стал бы)
На Си не стал бы писать пользовательский софт не связанный с работой с железом, а на asm не стал бы писать там, где владею достаточным количеством ресурсов (памяти, процессорного времени), что бы позволить себе использовать другой, более удобный инструмент.

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

Итак, сейчас речь по сути о четырёх технологиях:
C#, SQL (MSSQL в частности), DELPHI, PHP

В какой мере вы владеете каждой из этих технологий?

P. S. Честно признаюсь, у меня вообще нет опыта работы с C# (есть знания ровно настолько, насколько он похож на C++). По сей причине я не веду споров о том, что лучше C# или PHP. Потому что слабо знаком в преимуществами первого перед вторым (кроме быстродействия первого).

Petro123автор топика вроде про БД вообще не спрашивал.
Странно как это мы в сторону от виджетов ушли).

Это у нас беседа о том, что не следует бизнеслогику толкать в хранимые процедуры в MSSQL, как сделал это автор топика :) Начали с того, что эту идею озвучил skyANA под предлогом сложного масштабирования такого кода. вадя же начал спорить, но когда потребовали конкретный ответ "как" - он слился с ответом "задай это лучше в соответствующей ветке" (другими словами "я не знаю", и источников в подтверждение своих слов не имею)

Дальше я выразил свою идею, что не следует бизнес логику реализовать в БД ещё и потому, что есть инструменты удобнее для этого. Но вадя, уже дважды не сумевший подкрепить свои слова должной аргументацией снова начал спорить, что это не так и на SQL писать бизнес логику удобнее (проще, быстрее и дешевле)...

Вот так и перешли к обсуждению. На вопрос автора уже ответили: оптимальные варианты с учётом имеющегося это или C# или PHP. Теперь хочется определиться насколько стоит слушать советы от вади в принципе в будущем. Если он сольётся в 3 случаях из 3, значит... кхм... не буду произносить это в слух :))

skyANAавтор топика определился и пилит виджеты на JavaScript, админку на ASP.NET MVC :)

Как узнал то? :)

вадяsql в данном списке не по месту, в проекте должен быть элемент хранения данных - любая СУБД

Ты сейчас сам признался чтоль в том, что SQL не годится для реализации бизнес логики? Что это технология предназначена для работы с хранимыми данными (их запись, преобразование и чтение/выборка по определённым критериям)?

Ещё раз спрошу. На каком языке следует реализовать бизнес логику десктопного или web приложения?
1. MSSQL
2. DELPHI
3. C#
4 PHP

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

schi пропущено...


Ой. Мой день сделан.


такой ответ достаточен?

Это достаточный ответ для слива из беседы :) В данном случае это вообще цитата какого-то тролля, которого я решил проигнорить. Я с таким же успехом могу забегать и случайным образом подкидывать такой коммент на форумах по Perl или Scala, которые в глаза видел раз в жизни и то нифига не понял :)
Крайне бессмысленное поведение

вадяавтор
вадя
sql в данном списке не по месту, в проекте должен быть элемент хранения данных - любая СУБД


Ты сейчас сам признался чтоль в том, что SQL не годится для реализации бизнес логики? Что это технология предназначена для работы с хранимыми данными (их запись, преобразование и чтение/выборка по определённым критериям)?

Ещё раз спрошу. На каком языке следует реализовать бизнес логику десктопного или web приложения?
1. MSSQL
2. DELPHI
3. C#
4 PH
не надо путать мух с котлетами
в данном случае я указал только одну из возможностей баз - хранение данных, (основную)
и я не говорил такого бизнез логику можно реализовать используя все перечисленые технологии соединив их операторами & , | , &|
от поставленной задачи, знаний разработчика.
я использую java+mysql , и выбираю где реализовать логику таким образом чтоб было проще , быстрее, нагляднее
под каждый кусок проекта.

Интересный подход - проектирование структуры приложения в зависимости от знаний разработчика :)) Я зачастую выбираю инструменты в зависимости от доступных ресурсов (разработчиков, списка самих инструментов) и требований (быстро, дёшево, что бы легко найти разработчика для допилов, что бы было побольше бесплатных готовых решений), а вот проектирую так, что бы строго разделить компоненты системы и что бы каждый из разработчиков получил на реализацию конкретный интерфейс со строго определённым поведением без приписок "Посоветуйся с Петей" или "Спроси у Маши" :)

Ладно, мне Ваш подход к работе и проектированию понятен... Если у Вас будет разработчик хорошо знающий бэйсик и немного знаком с php, то после найма его на работу ваша система начнёт мигрировать на бейсик... А если придёт "ко власти" высококачественный питонщик, то на готовые модули начнут навешиваться обёртки из питона (или наоборот). А потом Ваш шэф начнёт молиться, только бы в штате не появился Си программист