D3lphi

Хочу понять, как работать и использовать GIT, чтобы база данных, которая обновляется на продакшене, на локальной машине была тоже в актуальном состояние, с одной команды в консоли, как в случае с файлами.

Это шутка такая или что? Вы на продакшене сервере обновляете базу данных без тестирования оной на локальных машинах? Вот прям берете и вносите изменения на пофиг?

Вы слышали о такой вещи, как миграция базы данных? Так вот эта вещь как раз таки и предназначена для того, чтобы структура бд находилась в системе контроля версий. У вас есть файлы, в которых описана структура, разработчик, сделавший изменения в файле миграции (а следовательно, и в бд), отправляет этот файл(ы) в git, а другие разработчики получают из репозитория этот файл и обновляют локальную базу данных. В популярных php фреймворках уже присутствует эта возможность из коробки.

Пример файла миграции фреймворка Laravel.

Потому что куки устанавливаются по средствам отправки заголовков ответа. Заголовки отправляются перед тем, как вы выводить что-то (через echo, например). $_COOKIE же в свою очередь заполняется при получении заголовков запроса. То есть, до начала выполнения кода. Таким образом, получается, что этот массив во время выполнения скрипта первый раз пуст.

Получается такая схема:

Первое выполнение скрипта:
1) Приходят заголовки запроса (Куки отсутствуют)
2) куки отсутствуют -> массив $_COOKIE пуст
3) Устанавливаем куки (массив $_COOKIE все еще пуст)
4) Отправляем заголовки ответа (массив $_COOKIE пуст), устанавливаем куки на клиенте

Второе выполнение скрипта:
1) Приходят заголовки запроса -> в них уже есть куки.
2) $_COOKIE теперь содержат то, что мы установили во время выполнения предыдущего скрипта.
...

Само SPA приложение делится на 2 основные части:

1. Frontend - верстка, логика на vuejs, роутинг (vue-router).
   
2. Backend - по сути, API к которому Frontend делает асинхронные запросы, получает данные и меняет представление соответствующим образом.
   

Эти 2 составляющие пишутся отдельно (От слова "вообще").

Например, так:

class Test
{
    private $tableName;

    public function __construct($tableName)
    {
        $this->tableName = $tableName;
    }

    public static function table($tableName)
    {
        return new self($tableName);
    }

    public function delete()
    {
        // do something
    }
}

Она идёт с phpstorm по-умолчанию. Зажмите ctrl и щёлкните ЛКМ по названию(вызову) встроенной функции/метода/класса и тд. В phpstorm откроется документация об этом элементе.

echo strlen('example'); // Щелкаем ЛКМ с зажатым ctrl по strlen и попадаем на страницу с информацией о данной функции.

Поэкспериментируйте с этими значениями, чтобы вам было удобно.

Очевидно, что вы используете новую версию PHP, в которой удалено устаревшее расширение mysql_*.

Да, по реализации все верно вы себе представляете.

Как все это смотрится с AR?

Откровенно скажу, с AR это смотрится хреново. В том смысле, что вы не используете основные "преимущества" (Да, да, в кавычках, потому что эти самые преимущества облегчают и ускоряют разработку, но никак не способствуют улучшению качества кода и его поддержке) этого паттерна.

В каждом из таких репозиторий будут повторяющиеся методы: all, find и прочие. Как быть в таком случае? Как вынести подобные методы в общий класс?

Создать базовый интерфейс для всех репозиториев и в нем описать эти методы, затем расширить интерфейс каждого конкретного репозитория. Можете плюсом ко всему написать абстрактный класс репозиторий и в нем написать универсальную реализацию этих самых общих методов (Для каждого типа репозиториев, разумеется). Но лично я бы так делать не стал.

Правильно ли я размышляю вообще?

Да, по реализации все верно вы себе представляете.

Здесь плохо всё, к сожалению.

Начнем с того, что вы неверно наследуете классы. Почему у вас класс, отвечающий за подключение к базе данных является родителем класса, работающим с заказами? Наследование применяется, если можно сказать, что что-то является чем-то. Например, разработчик является работником; компьютер является устройством и тд. Здесь же у вас вообще близко такой логике не получится следовать. Вы должны передавать хотя бы объект для работы с бд через инъекцию, например, в конструктор. В идеале, нужно использовать паттерн репозиторий для работы с базой данных.

Класс SearchOrder у вас не только выполняет запросы, но еще и работает с данными, хранит состояние этих самых данных, фильтрует данные (strip_tags()). Непорядок. Это все нужно разделять. У вас вообще получаются какие-то богообъекты, которые умеют во все.

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

$result = $wrapper->select("SELECT * FROM `tablename` WHERE `id` = :id", ['id' => 5]);

?

Вы вызываете connect() в методах. То есть, каждый вызов этого метода будет приводить к установке нового соединения с базой данных, даже если оно уже было установлено. Соединение с базой данных это достаточно дорогостоящая операция.

Зачем вы используете свойства, если можно обойтись обычными локальными переменными:

$this->orderID = (int) strip_tags($orderID);
$this->column = (string) strip_tags($column);
$this->value = (string) strip_tags($value);

?

Почему вы стриппите тэги у идентификатора? вы настолько не уверены в том, что влетает в функцию:
strip_tags($orderID);
?

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

if (!is_string($arg)) {
    throw new InvalidArgumentTypeException('string', $arg);
}

Это в идеале. Вы не обязаны это делать, конечно же. Но вот такие проверки делают приложение безопаснее. Хотя, опять же, повторюсь, в 2017 нужно начинать новые проекты на php 7.1+.

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

Кроме всего прочего, почитайте про стандарты оформления кода. Вы им не следуете.

Вам пока рано писать такие велосипеды. Судя по всему, у вас нет опыта вообще. Посмотрите готовые решения: фреймворки, ORM, изучите их, хотя бы поверхностно разберитесь, как оно работает и уже потом пробуйте что-то сделать, исходя из полученных знаний.

Желаю успехов!

Стесняюсь спросить, json_decode() вас чем не устраивает?
У меня на ПК обработка json-файла размером в 130 мб занимает чуть больше секунды.

$auto = Auto::create([
    // ...
    'key1' => 'val1',
    'key2' => 'val2',
    // ...
]);

User::create([
    // ...
    'auto_id' => $auto->id, // Ох уж это магия... Создайте лучше геттер.
    // ...
]);

Или

$id= Auto::insertGetId([
    // ...
    'key1' => 'val1',
    'key2' => 'val2',
    // ...
]);

User::insert([
    // ...
    'auto_id' => $id,
    // ...
]);

Можно связать "модели" отношениями и делать так:
$user->auto()->attach($auto);