Мирон, этот забавный технический артефакт, который вы описали тем не менее не является основанием к переписыванию приложения. Поскольку вы ссылаетесь на performance issue (PI), то данный issue надо бенчмаркать и делать justification.
Если у вас есть ссылка на github или другой источник который моделирует проблему - то буду признателен.
Тут еще есть другая проблема. Merge изменений. И с такими источниками как сайты - это нетривиальная задача. Убивать всю базу - дорого. Мержить корректно с сохранением ссылочной целостности - сложно. Простой пример - переименование какого-то продукта или торговой марки. Что делать с теми данными которые уже есть? Как детектировать что продукт был переименован а не создан новый?
Я вот думаю что сама идея парсить два разных сайта и потом сливать это в единую реляционную БД - обречена на неудачи. Тут очень много условностей. Может быть даже лучше все спраршеные данные сливать в какую-то NoSQL систему наподобие MongoDb или CouchDb в виде документов и уже организовать поиск по ней. Причем сливать всё что есть. Почему я ратую именно за такой подход. В современном мире BigData например в цепочке ETL уже стали отказываться от трансформации. Грубо говоря сливают все что есть в raw (Lake) и потом уже строят представления или материализуют то что есть. Если вспоследствии аналитик захочет новый атрибут который был спаршен - его можно будет достать и добавить в Mview. Но в случае с реляционным подходом такая затея обречена на неудачу. Мы ведь не парсили нужный атрибут. Кроме того если к двум сайтам еще добавить десяток - а в них совершенно другая схема и смыслы полей - другие.
Но ведь экспертный вопрос по реляции остался. Как относятся рестораны и сервисы? Один ресторан обслуживается одним сервисом? Или многие с многими? Города - тоже самое.
Вот ее нужно просто детализировать и описать как сервисы доставки (это тоже сущность) связаны с городами, ресторанами и продуктами. В лучших традициях проектирования баз данных. Тоесть отразить эту сущность на реляционной или концептуальной модели.
Можно конфиги просто хранить в git-репозитарии (приватный) и оттуда ставить на сервер. Таким образом задача бэкапа решается с другой стороны. Изменения конфигов тоже идут со стороны git.
Копирование базы на флешку - по другому конешно но есть у меня сомнения в полезности этого действия. Хороший хостинг и так обеспечивает бэкап баз.
Лексер и парсер как термины возникли еще в XXm веке. Это как основы теории трансляторов. И спокойно себе существовали. Vizitor и прочие шаблоны - это уже конец 20 го века и книга Четвёрки бандитов где собственно визитор и был описан.
Если вы не можете втащить Визитор в задачу трансляции то это даже хорошо. Это говорит о том что шаблон там просто не нужен как отдельная сущность. Одним из признаков хорошего проектирования кстати является доказательство ненужности того или иного шаблона. Это как исскуство Кун-фу. Ученик ищет повода подраться. А учитель или мастер - вообще ищет способа как-бы бой не состоялся.
Можно сделать циклический sequence от aaaa до zzzz и применить к нему симметричный шифр (типа книги кодов) и мы получим случайный неповторяющийся строго на данном интервале генератор.
Но как такое сделать только средствами PG - я не знаю.
Кстати, почему random выдает только вещественный результат? Есть ли функция где int/bigint на выходе?
В этой схеме слабое место - это вечные ключи. Стоило бы придумать их протокол ротации. Потому что чем дольше ключ где-то лежит тем больше вероятность его компрометации. В противоположность например сертификаты - имеют прошитый срок действия и все ПО которое с ними работает принимает такой протокол. Сертификат протух - надо его переиздать.
PHP мне кажется имеет смысл изучать если вы точно идете на поддержку старых приложений на базе WordPress и заказчик вам прямым текстом говорит что нужны знания PHP и доработка фреймворка. В остальных случаях я думаю что лучше смотреть в что-то более свежее например Node как язык back end разработки.
Также PHP может быть хорошим быстрым стартом для студента который хочет быстро войти в айти или для свитчера который уходит из смежных технологий и просто хочет осмотреться.
Данные с акселерометра могут показать что телефон лежит в покое больше нескольких часов. Это сильно отличается от обычного режима ношения телефона в кармане к примеру.
Где-то читал про 19 способов инициализации переменной. В бытность С++ кодинга я использовал максимум 2 способа. На данный фокус с декларацией функций можно посмотреть с позиции новых стандартов С++17 например.
Раньше трекеры учитывали ratio. Типа насколько ты хорошо раздаешь. Сейчас кажется всем пофиг.
Но мне кажется что твой статус сидера не изменится если ты будешь раздавать быстро или медленно. Сидер - он везде сидер.