Это был типичный подмосковный ЖК, коих сотни. Именно в таком ЖК произошла история, описанная в этой статье. В конце написал что есть еще некоторые идеи и вот руки дошли и до одной из них.

Все мы знаем что домах 1.5 тыс. домов довольно важно иметь хоть какой-то справочник по квартирам для быстрой связи с собственниками или проживающими. Обычно это exel табличка в виде НОМЕР КВ. - НОМЕР. Но у нас есть бот всеобъемлющий все чаты ЖК, поэтому я решил пойти своим путем.

Для начала я подумал какие данные можно собрать, а какие наверное не стоит. Учитывая что имена и номера - это конфиденциальные данные человека, которые я не имею права хранить, формат хранения такой:

дом-секция-этаж-квартира-имя-id-авто

где:

Имя - ник или при его отсутствии имя в телеграмме. Благо python любезно может реализовывать такие логические выражения очень просто. Также нужно учесть что многие пользователи телеграмма не заполняют поле last_name и просто оставляют его пустым. в таком случае будет передаваться None. Учитывая все вышеперечисленные проблемы я рекомендую использовать вот такой формат:

call.message.reply_to_message.from_user.username or (str(call.message.reply_to_message.from_user.first_name) + " " + str(call.message.reply_to_message.from_user.last_name or ""))

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

"^[а-яА-ЯёЁ][0-9]{3}[а-яА-ЯёЁ]{2}[0-9]+$"

А теперь к решению вопроса о хранении всего этого добра. Я решил не использовать реляционные БД просто потому что она мне в целом не нужна + мне довольно сложно не имея соответствующего опыта разворачивать сервер БД без графического интерфейса. Поэтому я сделал просто txt файл и храню данные именно в таком формате как я указал выше. данные разделяю по порядку через "-". Работает быстро, записывает быстро. Но есть момент. приходится при изменении данных удалять предыдущую строку, двигать весь список вверх на -1 от текущей позиции курсора в файле и записывать снова всё что было ниже + строку, измененную пользователем.

def edit_user(self, call):
        for i in self.coincidences:
            self.lines.pop(i[1])
        with open("chess_neighbors.txt", "w") as file:
            for text_str in self.lines:
                file.write(text_str)
        self.add_user(call)

не сложно, но не красиво. Однако работает.

Формат взаимодействия пользователя с шахматкой такой:

т.е. просто перечисляем цифрами дом секцию этаж квартиру через пробел с командой /шахматка в ответ на сообщение нужного пользователя, а уже их его сообщения берем id имя usera.

Интерфейс поиска имеет несколько вариантов:

Поиск по этажу. если бы было указано например /найти 4 8  - мы бы получили всю секцию. Формат вывода неверный, прошу прощения.
Поиск по этажу. если бы было указано например /найти 4 8 - мы бы получили всю секцию. Формат вывода неверный, прошу прощения.
Поиск по контакту. Просто отвечаем командой поиск на сообщение нужного человека. В таком режиме поиска можно удалить найденную квартиру, если человека неверно отметили в шахматке
Поиск по контакту. Просто отвечаем командой поиск на сообщение нужного человека. В таком режиме поиска можно удалить найденную квартиру, если человека неверно отметили в шахматке

а также по номеру авто соответственно /найти м000мм000 например.

К сожалению люди неохотно отмечаются в своих квартирах. Но админы потихоньку заполняют данные. И более неохотнее отмечают номер своих авто. Возможно в будущем мы соберем достаточно данных чтоб закрыть чаты домов для неотмеченных пользователей... но это уже совсем другая история.

Комментарии (13)


  1. lovermann
    00.00.0000 00:00
    +9

    Судя по самим данным, они требуют более серьёзного подхода для организации. Наверное, не очень хорошо иметь открытую базу по всем жильцам, месте их проживания и ещё автомобилях. Юзер-менеджмент надо придумывать, чтобы доступ был только у жильцов, но тут же и квартиросъемщики, родственники, коллеги по работе, любовники/любовницы и вообще фиг знает, кто.

    Я думаю, что лучшая идея, — вообще такую базу не делать :)


    1. mosx1 Автор
      00.00.0000 00:00

      доступ имеют только ограниченное число админов чатов. запрос на поиск могут делать только они.


    1. Tzimie
      00.00.0000 00:00
      +1

      У нас у охранника в тетрадке чтобы знать кого вызванивать если один запер машину другого


      1. lovermann
        00.00.0000 00:00
        +5

        Ну, тетрадка защищена лучше, чем все бот-базы и имеет прямой практический смысл. Она лежит у человека, который здесь и сейчас должен решить проблему и он её решит. Это как раз ОК.


        1. Layan
          00.00.0000 00:00

          Так это получается и бухгалтеру безопаснее весь учет вести в тетрадке?


          1. Rinsewind
            00.00.0000 00:00

            Тетрадку и уничтожить проще, случись чего


          1. BadHandycap
            00.00.0000 00:00

            Безопаснее, но не проще.


  1. IgorRJ
    00.00.0000 00:00

    Ой, мама рОдная! Не иначе, за автором гнались семеро с дубинами и лопатами. Ну можно же прогнать свой опус через спеллчекер. Читать ведь невозможно.


    1. UMenyaNeudobnieVoprosiki
      00.00.0000 00:00
      +4

      За автором гнался пристав с повесткой в суд о незаконном сборе конфиденциальных данных)


      1. tugrikk
        00.00.0000 00:00

        Точнее персональных данных.

        КоАП РФ Статья 13.11.пункт 8
        "Невыполнение оператором при сборе персональных данных, в том числе посредством информационно-телекоммуникационной сети "Интернет", предусмотренной законодательством Российской Федерации в области персональных данных обязанности по обеспечению записи, систематизации, накопления, хранения, уточнения (обновления, изменения) или извлечения персональных данных граждан Российской Федерации с использованием баз данных, находящихся на территории Российской Федерации, -

        влечет наложение административного штрафа на граждан в размере от тридцати тысяч до пятидесяти тысяч рублей; на должностных лиц - от ста тысяч до двухсот тысяч рублей; на юридических лиц - от одного миллиона до шести миллионов рублей.

        (часть 8 введена Федеральным законом от 02.12.2019 N 405-ФЗ)"

        В общем, кто ни будь пожалуется из жильцов, которых отключать планируют за непредоставление данных и будет не до смеха, а за повторные нарушения там ещё больше.


        1. dartraiden
          00.00.0000 00:00
          +1

          Государственный номер автомобиля не является персональными данными, поскольку относится к транспортному средству, а не к физическому лицу.

          То, что по каким-то незаконно слитым базам можно «пробить» человека, вписанного, например, в полис ОСАГО, дела не меняет (а порой даже там больше одного человека).


  1. Survtur
    00.00.0000 00:00
    +3

    Я решил не использовать реляционные БД просто потому что она мне в целом не нужна + мне довольно сложно не имея соответствующего опыта разворачивать сервер БД без графического интерфейса.

    Посмотрите в сторону sqlite - безсерверная БД хранимая в файле. Отличный стандартный модуль в python для работы. Это точно удобнее, чем текстовый файл.


    1. mosx1 Автор
      00.00.0000 00:00

      Да. Спасибо.