4X_Pro

Я придерживаюсь мнения, что один из признаков технически хорошо сделанного сайта — неотличимость снаружи от сайта на статике (даже если на самом деле всё работает на супернавороченной CMS). Поэтому на этапе создания страницы смотрим, будут ли у неё дочерние элементы. Если нет, то делаем с расширением .htm или .html, если могут, то с / на конце.
Пожалуй, самая большая разница, которую нужно учитывать — это формирование относительных ссылок. В случае, если на странице с URL /razdel/tema мы сделаем относительную ссылку second-page, то она будет вести на /razdel/second-page (что нелогично, так как это шаг на уровень выше), а если на странице, у которой URL -- /razdel/tema/, то на /razdel/tema/second-page.
Исключение — это идентификаторы GUID во всяких REST API, которые пользователь никогда в адресной строке не увидит, и где данные отдаются в JSON или XML, там лучше обойтись без / просто ради экономии траффика.

Да, всё верно, это происходит, если добавлять стили через JavaScript с помощью конструкций вида

var sheet = window.document.styleSheets[0];
sheet.insertRule('.container { width: 100%; margin: 8px auto }', sheet.cssRules.length);

Подробнее — см. в MDN: https://developer.mozilla.org/en-US/docs/Web/API/C...

Обычные сайты-конструкторы — нет. В англоязычном Интернете есть несколько проектов, предоставляющих на платной основе платформы с функционалом для соцсетей. (В Рунете ничего подобного не видел.) Но это — плохой вариант, который уместен только в том случае, если запустить сеть нужно очень срочно и с обычным функционалом, без добавления чего-то своего.
Если же делать нормально, то AlexVWill правильно посоветовал использовать готовый open source-движок. Его нужно поставить на обычный хостинг или VDS, и дальше дорабатывать для своих нужд. В частности, если вам нужен аналог ВКонтакте, то есть такой проект OpenVK.

Вообще, более правильным является такой вариант:

<link type="text/css" rel="preload" as="style" href="home.css" onload="this.rel='stylesheet'"/>
<script>
// Firefox не грузит стили с preload автоматически, 
// поэтому в конец HTML-кода нужно добавить такое (один раз):
if (navigator.userAgent.indexOf("Firefox")>=0){
var elms = document.querySelectorAll('link[rel=preload][as=style]');
for (i=0; i<elms.length; i++){
elms[i].rel="stylesheet";}}
</script>

Стоит ли разделять стили — сложно ответить однозначно. Когда файлов много, и часть стилей дублируется, сложнее вносить изменения (приходится дублировать их в каждый файл), зато меньше траффика для пользователя и лучше скорость загрузки. Соответственно, тут нужно смотреть, насколько у раздельных файлов размер меньше, чем у общего. Если в 2—3 раза, а сайт требуется модифицировать редко, то можно разделить. Если на сайте то и дело что-то доделывается, то лучше обойтись одним app.css.
И ещё: те стили, которые описаны в теге

Максимум, что можно сделать — это вставить вот такой input:

<input type="file" accept="image/*" capture="camera" />

По щелчку по нему на мобильных устройствах будет вызываться камера, а не выбор файла, как обычно. Дальше можно на событие onchange для этого input повесить отправку формы на сервер. А вот распознавание кода и всю последующую обработку придется делать на сервере. Или писать полноценное Android-приложение.

А зачем такое делать на NoSQL? Тут реляционные базы вполне подходят.
Я бы вообще ограничился тремя таблицами:
1) сайт
2) товар вообще (по сути, там хранится только его id и наименование)
3) товар на конкретном сайте (тут хранится id товара, id сайта, цена, дата парсинга).

Сделать так: проверять наличие файла с определенным именем где-ниубдь в /tmp или /var/run, если он есть, то тут же делать выход из скрипта, если нет, то создавать такой файл, после чего выполнять необходимую работу и удалять файл перед завершением скрипта, если оно проходит корректно.