Ответы пользователя по тегу PHP
  • Как лучше (дешевле) хранить справочники?

    @thyratr0n
    Вижу, народ тут нормализацией увлекся. Поясню: есть 6 форм нормализации, а есть суровая реальность. Точка. И нечего тут в адрес Алексей Черемисин указывать на какие-то нарушения.

    Справочники нужно хранить так, как это возможно. Если данные однотипны:
    1) если данные в них однотипны, можно скидать все в одну таблицу, запилив составной РК (type, key) или по старинке одинарный - это как душе угодно (пока количество записей не более, чем 6-ти значные, разницы не будет);
    2) можно то же самое запилить в разных таблицах - на вкус и цвет, как говорит.
    Если же данные разнотипны, то:
    1) можно в разных таблицах, если по отличающимся полям может идти фильтрация;
    2) можно все в одну таблицу, запилив какое-то "сложное" поле с типом TEXT/BLOB/VARCHAR, куда писать отличающиеся данные.

    Все, никакими тут нормализациями и не пахнет. Всем добра.

    P.S. Дмитрий Ларин вам следует более точно формулировать свои вопросы, ибо "Без ТЗ результат ХЗ" (с)
    Ответ написан
  • Как правильно реализовывать модели в MVC структуре сайта?

    @thyratr0n
    Существует множество подходов к решению этой проблемы. Все зависит от того, сколько времени вы готовы потратить на их реализацию, а так же от используемых фреймворков. Если вы говорите про "модель", значит, вы используете паттерны либо ActiveRecord, либо Table.

    1. Если вы используете готовые фреймворки, то юзайте инструментарий "из коробки" - для учебного проекта этого будет достаточно.
    2. Если вы сами пишете, то тут возможны варианты:
    2.1 Можно создавать классы-компоненты (storage), которые будет организовывать выборку и нужным образом компоновать классы между собой:
    2.2 Можно создать в БД вьюхи (view), которые объединят нужные данные, а в коде использовать, как единую сущность.
    2.3 Можно написать постобработку для CRUD-операций (триггеры в БД, events в коде и тд), которая будет собирать все данные в четвертую таблицу, отдельную. Тогда просто один класс доступа будет.

    Варианты во 2-м пункте расположены по возрастанию уровня сложности.

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

    class Comment
    {
        /**
         * Я бы еще рекомендовал передавать связанные сущности в конструктор, ибо без них комментарий не имеет смысла
         * @param User
         * @param File | null
         **/
        public function __construct(User $user, File $file = null); //я б
      
        /**
         * тут никаких интерфейсов, ибо интерфейсы, дублирующие сущность - моветон
         * @return User
         **/
        public function getUser(): User 
        
        /**
         * @return File
         **/
        public function getFile(): File
    }

    Либо использовать фабрики. Но фабрики - это уже "на вкус и цвет", как говорится.
    Ответ написан
  • В какой момент пора использовать ООП?

    @thyratr0n
    Что-то даже хз, что и ответить... ООП - это принципиально иная парадигма разработки, нежели процедурный стиль. Вообще, ваш случай довольно интересный, когда аж 5 лет устраивает процедурный стиль.
    Во всяком случае, на текущих проектах ООП лучше не внедрять (огребете проблем). А вот что-то новое можно и начать.
    Ответ написан
  • Как ускорить работу программисту?

    @thyratr0n
    Вот, никогда не задумывался над этим.
    Говоря о себе... Я не использую ни таймтрекеры, ни тайм-что-то-еще, ни фломастеры (тем более цветные), ни тетрадки, и тд, а так же не смотрю на других коллег. У меня такой склад ума: меня всякие "рисовалки", коллективное планирование и тд только отвлекают и утомляют. Возможно, из-за этого мне будет сложно что-то внятное посоветовать, но...
    1. Работать, как можете. Не надо стремиться к звездам, ибо, если задатки есть, оно само проявится. Так у вас выработается правильная самооценка.
    2. Читать литературу, умную, и не "С++ за месяц", а "Архитектура корпоративных приложений" и иже с ней. Так у вас появится теоретическая платформа для понимания как микро-архитектур, так и более серьезных вещей.
    3. Наблюдать за собой, чтобы понять: в какие периоды суток вам наиболее комфортно работать (в какое время у вас наиболее высокая производительность), и какие факторы на это влияют. Так вы сможете планировать.
    4. Не стремиться заучивать наизусть синтаксис и семантику языков, но знать какие-то общие вещи, а так же места, где можно быстро найти ответ. Так у вас появится свободное место в голове.

    В общем, трудитесь, читайте литературу, и все будет хорошо.
    Ответ написан