• Правильная архитектура задачи под Laravel?

    Dase23
    @Dase23
    back-end developer
    Модель для связи не нужна.
    Связь создается уже внутри моделей с помощью методов
    BelongTo
    HasOne
    HasMany
    итд


    И все таки мне кажется удобнее было бы под каждый датчик завести свой контроллер и свою модель.
    Так как они выполняют достаточно разные функции и значения у них тоже разные. Если мы пытаемся термометр у которого значение одно и в градусах, связать в единой таблице с датчиком ИК движения у которого свойств может быть уже 5 и естественно в совершенно других значениях. Что вынуждает нас либо нарушать все возможные НФ, либо плодить кучу связных таблиц. или же еще хуже использовать модель EAV


    В общем я вижу ситуацию так
    • Мы знаем все о наших датчиках и платах поэтому можно не пытаться делать их универсальными гораздо проще будет работать с датчиком как с конкретным элементом это будет и приятнее и более функционально и меньше геморроя вы попытках все делать универсальным помните про KISS


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


    • в этих же контроллерах модели в бд храним поведение датчика на плате опять все просто и легко



    в конце концов SQL хорош когда нам нужна целостность данных) а тут можно вообще все в паре ключ значение запихать в REDIS и не париться вообще + работать будет быстрее)
    Ответ написан
    5 комментариев