Adamos, в принципе, ничто не мешает организовать написание кода так, чтобы он на одной платформе превращался в dll, а на другой - в lib.so. Да, придётся заморочиться, но если автор хочет действительно переносимое решение для полноценно компилируемых языков, то ему это может быть интересно.
Это обычная практика для сервисов такого размера - делегировать муторную рутину на партнёров. Viber тоже на партнёров кивает при попытке подключить их платный сервис (Viber Business Messages). А партнёры уже знают, как всё делать, ну и у них на сами сервисы есть свои выходы.
Если хочется именно надёжный сервис для бизнеса и не хочется регулярно менять номер из-за внезапно случающихся блокировок - то заморочиться имеет смысл. В конце концов, все эти нецелевые использования WhatsApp Web - всего лишь полумеры.
Много клиентов на одном телефоне не запустишь. Читал, что есть у кого-то из китайцев "двойной режим", где можно приложения ставить в двух экземплярах, они будут иметь отдельные настройки и не знать о существовании друг друга, как раз для запуска двух аккаунтов одного мессенджера сойдёт. Но сомневаюсь, что можно запустить сразу десяток, да и не потянет телефон наверняка такое. И в теории WA может заметить, что на устройстве с одним hardware запущено много клиентов сразу.
Я всё же говорил о программных эмуляторах. Серверная винда не нужна. На самом деле некоторые из эмуляторов даже кроссплатформены (как эмулятор из Android Studio), в то время как под Windows есть эмуляторы типа Bluestack Player, которые хороши сами по себе, но больше нацелены на то, чтобы пользователям запускать игрушки, а не автоматизировать работу каких-то приложений...
Но я во всех этих эмуляторах не очень разбираюсь и ничего советовать не могу. Народ как-то это дело даже автоматизирует...
Amigun, можно посмотреть как это сделано в verlihub https://github.com/verlihub/verlihub, там плагины - это подгружаемые библиотеки на C++, а скрипты на других языках реализуются отдельными плагинами (LuaScript, PerlScript, PythonScript), которые уже умеют загружать скрипты и вызывать в них методы. При этом основной софт вообще не зависит от наличия библиотек этих скриптовых язык - они не нужны, пока не понадобятся.
Блин, написал ответ по-дискордовски, а потом посмотрел, кто пишет :)
Если это опять vk-бот, то советую посмотреть на то, имплементирует ли он ctx.author как Discord, тогда вместо user.first_name лучше брать ctx.author.first_name. Также, возможно, там работает type hint, как в discord.py, когда можно у параметра указать тип аргумента как member:discord.Member и он его автоматом превратит в инстанс этого класса, так что можно обращаться к нему со всеми его полями. В частности, в discord.py есть member.mention, который и надо использовать вместо @id.
Также надо использовать f-строки, вызов format на одну переменную вообще лишён смысла (а если там у юзера встретится {} в имени - то ещё и вызовет ошибку). Называть переменную list очень плохо, так как это название встроенного класса - можно где-нибудь прилично выстрелить себе в ногу.
В общем случае никак, так как эти боты работают от аккаунтов обычных пользователей. В том числе в теории это могут оказаться и взломанные аккаунты пользователей, которые уже раньше были в чате, вели себя нормально и прошли любые верификации.
Для каналов проблем нет, так как список подписчиков канала видит только админ.
alextimson, чтобы это была именно команда, нужен класс discord.ext.commands.Bot, который порождён от discord.Client и расширяет его функционал. В discord.Client нет команд, но их можно имитировать путём парсинга сообщений в event on_message. События с именем info в Discord не бывает, поэтому подобая функция будет делать совсем ничего.
Зачем в reviews есть ФИО, если они есть в persons? И не стоит где-то называть person, а где-то user. Если их функции различаются, то это должны быть разные сущности. Возможно расширение функций, когда, например, user может быть клиентом магазина, а может быть владельцем/менеджером, тогда это могут быть таблицы с допсвойствами и ссылкой на первичную таблицу по id (user-shop_client и user-shop_manager).
У сообщения стопудово должно быть время отправки, по которому надо будет сортировать чат. Или можно по id сообщений сортировать, если id будут возрастать со временем. id и получателя, и отправителя не имеют смысла, если чат тет-а-тет, тут имеет смысл id только отправителя, который может совпадать с user_id в чате, а может быть user_id менеджера магазина (заодно можно, чтобы в магазине работали разные люди и могли независимо общаться с пользователями). Клиенту магазина можно не показывать имя менеджера, а показывать название магазина.
Хорошо бы навести порядок в английском. Massage - это массаж, правильно message; magazine - это журнал, правильно shop. ФИО лучше сортировать нормально (а не ставить отчество первым, хотя, конечно, в базе порядок столбцов неважен, но если уж проектировать, то аккуратно) и быть готовым к тому, что многие категорически не хотят его заполнять и будут ставить минусы или "нет" везде, кроме имени - короче, лучше разрешать их пустые значения. Вместо patronymic чаще всего поле называют middle name - это покрывает и понятие отчества, и дополнительные имена, существующие во многих культурах и странах.
products_id - почему во множественном числе? Лучше вообще единообразие: либо таблицы называются единственным числом (тогда красиво выглядят отсылки user.id, user.name), либо множественным (users), а ссылки как раз через единственное число.
При именовании таблиц и колонок не стоит использовать разный регистр и лучше воздерживаться camelCase. Всё равно большинство баз имеют регистронезависимые имена сущностей (и из-за этого приходится дополнительно напрягаться иногда). И не надо пробелов в именах. Названия типа name magazine тоже плохие, так как (на этом примере): 1. пробел вместо подчёркивания; 2. и так понятно, что магазин, по имени таблицы; 3. порядок в названии лучше более естественный; 4. это вообще-то магазин, а не журнал (см. выше) - короче, правильно просто name, даже не shop_name и уж тем более не name_shop. Вообще, это тот случай, когда уместен некоторый перфекционизм.
У покупателей часто бывает больше одного адреса: они могут заказывать домой, на работу, на дачу, в квартиру родителей итд. Имеет смысл также вынести в отдельную таблицу. Также часто выносят названия городов и областей в отдельные таблицы (словарь), а в адресе указываются id (через выпадающий список). Но если это учебная задача или проект небольшой, то можно не заморачиваться. Всё равно часто изменения таких вещей происходят с пониманием масштабов и специфики работы. Например, московские магазины могут при выборе Москвы предлагать улицу из списка, а при выборе подмосковных населённых пунктах - позволять вводить улицу вручную, так как база улиц каждого областного СНТ - это нереально.
Короче, улучшать можно почти до бесконечности. Особенно если дорасти до уровня всяких авито.
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-аккаунтами от имени этого бизнеса...
