Станислав Макаров

от "да, очень нужный скилл, будущее за вебом"

до "это днище..."

Это не взаимоисключающие вещи.
Скилл нужный, и он же - днище. Вот, как тут уже сказали - продавец нужный скилл, магазов и ларьков в стране много. То же и с фронтэндом. До чертиков однотипных задач, и все скучные как "Старик и море". Порог входа низкий. Результаты обычно оцениваются по принципу - "ну работает, красиво, не так уж сильно тормозит - все ок".

Вы Тостер полистайте, и посмотрите, по каким тегам спрашивают.

P.S. Вебу уже не первый десяток лет, веб это не будущее, веб это настоящее. А то, что перечисленные Александр школьники и инвалиды понимают под "вебом" странички с js-кодом, и даже не знают, например, что такое REST на самом деле - вот это результат низкого порога входа.

1. Аналогию с самими языками проводить не стоит. Аналогию стоит провести для платформ.
Платформы вроде .net и java, которые разрабатывались для энтерпрайза, разумеется лучше для него подходят. И не важно даже, десктопное у вас приложение или веб-сервис. Важно, что в платформе есть поддержка нужных стандартов и технологий с гарантией качества от производителя.
С другой стороны, многие компоненты таких платформ это closed-source. Поэтому, если вы не банк, а стартап, то для веб-сервиса выбирайте
Ruby или Python.
Социальную сеть можно сделать много на чем, но я бы делал на рельсах или джанге. А вот функционал сбербанк-онлайн я бы делал на ASP.NET MVC (т.е. на C#) или на джаве (на спринге например). Однако, тот же близзовский battle.net написан на спринге (сервер когда-то случайно отдал мне stack-trace после ошибки).

Хотя, имхо, некоторые ключевые элементы дизайна языка все-таки влияют на возможность его применения в крупных проектах. Например, я считаю, что писать крупные проекты на языке со статической типизацией намного проще. Однако это вопрос очень холиварный.

2. Нет, не будет. Не должно быть, если точнее. Для пользователя язык общения с сервисом - HTTP. Если в современном веб-фреймворке нельзя нормально абстрагироваться от используемой технологии, это плохой фреймворк.

3. На PHP много чего нельзя сделать. Вернее, КАК БЫ можно все, но нормально можно только веб. Именно поэтому для меня он не язык, а какой-то шаблонизатор - слишком у него дурная история и связь с веб (что нехорошо для языка общего назначения). Конечно, современные веб-фреймворки его очень хорошо причесывают, что даже можно работать с ним, но мы же о языках говорим..

4. Для веб-проектов между Ruby, Python и PHP человек бы выбирал исходя из своих умений. У каждого языка своя экосистема (библиотеки, пакетные менеджеры, серверы приложений/плагины для веб-сервера) и довольно непросто знать все сразу. Именно поэтому все расходятся по своим лагерям и просто работают. Первичный выбор языка часто определяет его популярность. Лет 5 назад Руби всех рвал за счет Рельсов, сегодня Питон и PHP подтянулись в плане экосистемы, поэтому ситуация уже другая.
Если человек таки сумел познакомиться с разными языками, он выберет тот, в котором ему проще мыслить. Модель ООП, статическая/динамическая типизация - все это определяет ощущения КОНКРЕТНОГО человека от КОНКРЕТНОГО языка.

5. PHP учится быстрее всех, но если вы не знаете других нормальных языков, лучше его не учите - испортитесь как программист. Python и Ruby учатся примерно одинаково. Изучение C++ - совсем другая история, я бы не ставил его в один ряд с Питоном - этот язык несколько другого уровня и требует других (более глубоких) знаний о вычислительной технике (т.е. он 100% учится дольше, чем Python).

Все зависит от того, что предполагается давать пользователю в управление. Если сервис таков, что юзер никогда-никогда не должен получать доступ к базе, то тогда можно в одном наборе таблиц. Хотя разные БД будут проще в администрировании и на порядок безопаснее (вдруг где-то забудете сделать WHERE по id магазина). Если между магазами не будет общих данных, тогда преимуществ от использования одной базы ИМХО практически нет.

Направление мыслей верное, с технической точки зрения тоже. Не уверен насчет необходимости обновления апдейтов и делитов - если вы уже проверили UserId и выяснили, что запись принадлежит конкретному пользователю, и получили ее Id - то и удалять уже достаточно только по Id (за исключением, конечно, случая, когда вам нужно удалить ВСЕ записи конкретного пользователя).
Правильность этого варианта зависит от вашей задачи. Если вам достаточно знать пользователя-владельца - то все хорошо, но если вы потом захотите более сложную систему доступа к записям - например давать и другим пользователям доступ к записям пользователя A, то и схема базы также усложнится.

Да чего вы паритесь, учите последнюю технологию. А если уж прям с нуля решили учить, то берите сразу ASP.NET 5 и MVC 6, они пока в превью, но я думаю довольно скоро будет релиз, в Update 1 или 2. А разработка под них будет отличаться довольно прилично от текущего workflow.
Вы бы еще спросили, надо ли знать WebForms чтобы учить MVC). Ну конечно, если вы будете знать оно пригодится, для общего представления о развитии технологий, от чего к чему пришли.

Несколько независимых рекомендаций
1. Многие из перечисленных вами требований стандартны для большинства современных информационных систем, и предментными не являются. Вам стоит обдумать конкретные требования и конкретные ваши процессы на предприятии или в исследованиях. Если не считать некоторых продвинутых требований (история и разграничение доступа по классам), то вы и описали что-то вроде Access, которое как бы "подходит" для всего.
2. Все-таки весьма сомнительно то, что вам нужна система для учета любых объектов, особенно с учетом того, что вы дали конкретное описание модели. Это бессмысленная цель, подобная система реально не упростит вам задачу. Вам стоит поставить конкретную задачу и автоматизировать ее. Невозможно получить что-то полезное на общем уровне, не вникая в детали. На общем уровне можно открыть Ворд или опять-таки Access, и забить в табличку данные.
3. Если вам важна привязка к карте, посмотрите в направлении GIS-систем. Многие из них предлагают что-то похожее на ваши требования - создавать объекты с любым набором свойств (помимо геометрии). Только обычно клиентский софт в таких системах используется для работы именно с геометрией - все прочие операции автоматизируются отдельно (тут полезно хранить данные в СУБД общего назначения, классика жанра - PostgreSQL + PostGIS).

P.S. Все-таки у вас видимо вполне конкретная задача, которую вы зачем-то пытаетесь обобщить. Система для учета любых объектов называется СУБД, а инструмент для выполнения операций и вычислений - языком программирования.

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

Это я все как дилетант говорю, эл. обучением не занимался. Это то, что я бы хотел и ожидал увидеть в такой системе.

www.readnotify.com

хотя не удивлюсь, если они и используют указанные вами методы.