Vitsliputsli, вставка там бывает очень редко и её скорость вообще не волнует, основная задача там - это вывести данные, а для этого единственное узкое место не в самих станциях, а в stations_of_lines, которые сделаны хреновенько, но переписывать лениво (можно в любой регион ткнуть и увидеть, что таблица грузится не супер быстро, но вполне приемлемо).
Лучше всего видимо всё же MediaWiki, если основная функция всё же развитая вики-разметка с шаблонами и категорями.
Скорее всего, в чистом виде готового решения не будет и придётся что-то допиливать или пересмотреть варианты решения (например, вместо хронологической линейки генерировать список годов с вики-ссылками на события).
Очень много чего интересного можно сделать с помощью шаблонов, правда, придётся мыслить по-шаблоновски :) Можно, например, посмотреть, как в Википедии устроен шаблон Location, который добавляет в статью координаты со ссылкой на карты (наверное, можно подпилить, чтобы выдавать всплывающее окошко с картой, например).
Как вариант, можно сделать класс с нужными данными пользователя, как class User в вышеприведённом примере, и держать в скрипте словарь, который отражает chat_id в User. При этом если chat_id нет в ключах - создавать новый пустой User (скорее всего, его можно создавать прям при /start. Отдельная задача - сохранять данные между перезапусками (в базе или в файле)
Или можно сделать аналогичную таблицу в базе и всё записывать в неё, при необходимости доставать, или можно хранить в скрипте выгрузку из базы, при чтении данных использовать её, при записи изменять и её, и базу. В общем, есть варианты.
yarovikov, обычных способов много, в том числе таких, которые сейчас уже в целом не принято делать (например hstore в Postgres считается устаревшим и рекомендуется использовать json). Более того, бывает часто так, что люди выбирают не самое удачное решение, а потом весь жизненный цикл проекта с ним мучаются.
Приведу пример из своей практики. Есть вот такой сайт: osm.sbin.ru/esr
Там есть супертаблица stations, в которой много колонок типа name_tr4, name_gdevagon, name_yarasp. Позже для новых данных я начал применять другой подход: каждый источник загружается в свою таблицу, а к общей таблице они подключаются через LEFT JOIN по ЕСР-коду. Это оказалось во многих отношениях лучше, например, гораздо удобнее обновлять данные источников. Но запросы стали более сложными. И до кучи далеко не по всем данным это переделано, тем более исходные источники ряда данных не сохранились и их обновить уже нельзя, только синтезировать разбором данных супертаблицы, что не особо имеет смысл теперь.
yarovikov, для начала, пересмотреть подход. Потому что таблица с 50-60 колонок - это, скорее всего, ерунда какая-то. Надо посмотреть, что в них, и решить, как лучше организовать. Например, можно класть некоторые "неосновные" параметры в отдельную таблицу с key и value. Типа такого:
Запись для id=1 name=foo description=bar lorem=ipsum vladimir=putin класть в две таблицы:
Это заодно позволит при необходимости расширять число полей. Неудобство - для получения информации нужно будет делать два запроса или join с постобработкой.
Можно также хранить дополнительные параметры в виде текстового поля, где, например, json, но тогда по ним нельзя будет фильтровать (но в реальных задачах могут быть примеры данных, где фильтровать по всем не нужно).
Можно использовать key-value фичи некоторых баз (поля типа json, hstore итд), тогда по ним можно даже фильтровать и в принципе можно даже строить индексы по конкретным key-value парам.
Наконец, если это данные, например, каких-то регулярных измерений, то возможно имеет смысл сразу подумать о специализированных базах или настройках к имеющимся базам для временных рядов.
Выбор решения требует слишком глубокого погружения в задачу: структура данных, объём, способы работы с ними...
Если там не нужны хорошие вычислительные ресурсы (например, распознавание голоса делается не нейронкой на localhost, а каким-то сервисом) - то вполне нормальная идея.
Владислав Лысков, строго говоря, процедура там и правда замороченная: надо зарегистрировать бизнес, пройти его верификацию, делегировать провайдеру сервиса право управлять WA-аккаунтами от имени этого бизнеса...
Xrey Monstrikov, на самом деле если хочется сделать что-то интересное - есть миллион более осмысленных и даже ценных задач. Например, можно попробовать помочь проекту https://t.me/ruarxive
Эти смс бесплатны только для тебя, но не для владельцев сайтов. Я даже больше скажу - для владельцев сайтов они дороже, чем для обычного рядового абонента мобильных операторов.
С Business API ничего на самом деле особо сложного, там главная беда для многих очень хотевших в том, что это не бесплатно. К провайдеру привязка может быть разве на уровне используемого протокола, а номер можно между ними мигрировать. На самом деле все партнёры WA хотят, чтобы подключались именно через них, поэтому стараются всячески помочь пройти все эти процедуры потенциальным клиентам.
Слава, это скорее свойство не Java или PHP, а свойство тех сфер, где они применяются: в Java заметный перекос в сторону энтерпрайза с повышенными требованиями и совсем другими бюджетами.
mkone112, это явно ирония над неким расхожим образом, которого иногда серьёзно, а иногла в шутку придерживается некоторая сторона. Так-то дофига народу мешает с грязью и питонистов, и джавоведов, и растаманов. У любого языка есть хейтеры, которые свои чувства проецируют на соответствующих разработчиков.
Steven Eaton, надо обе задачи сделать с асинхронными библиотеками и не страдать ерундой, потому что синхронный код в любом случае несовместим с асинхронным циклом событий. У телебота уже появилась асинхронная версия.
В ЕСР ~25 тыс. станций с учётом бардака кодов.