Как правильно назвать такое API?

[Full-R]

А как будет называться моя архитектура? Я взял mySQLi и объявил структуры таблиц в виде ассоциативного массива, где описана вся труктура, отношения и типы данных. К этой же структуре я передаю значения, которые нужно передать, тип запроса и имя таблицы. Получается, что я не пишу SQL, а передаю структуру массива таблицы и полей. Назвать это удалось ABS(Array Based Structure) и ABQ(Array Based Query), а движек я назвал DBX(Data Base X).

В принципе, я подумывал сделать (object)['struct'] => [ ... ] и обращаться к массиву, как к объекту, и, тогда это бы можно было назвать моделью, например, если сконструировать структуру для $dbx::getPage('123'), где в массив прописан value для id в SQL для получения нужной страницы.

Я долго втыкал в объекты на PHP и понял, что мне больше подходит массив(там типы и поля не работают все равно, а природа объекта из класса или STD не дает ни какой разницы в программировании ). Также объект жрет памяти и процессора в 4 раза больше. Я для остальных добавляю (object) перед array и все довольны

Как правильно назвать такое API?

 

[fixxxer]

Если я верно понял по описанию, это самая простейшая штука - table/row gateway - к которой прикручены relations. Моделей тут вообще нет, есть только работа с базой.

 

[Adelf]

Как правильно назвать такое API?

Массивной кашей)

 

[Full-R]

Если я засуну это в класс и добавлю аргументы - это будет моделью при условии синтаксиса object? Я просто не могу понять критику в свой адрес ... Объекты тоже изначально на строках написаны и работает все до сих пор на единицах и нолях так как персональных кватнтовых PC по доступной цене нет...

$STRUCT_NODES = [

    'field_id' => [

        'type'   => 'bignum', // big int
        'auto'   => true,     // auto increment
        'length' => 255,
        'value'  => 0

    ],

    'field_country' => [

        'type'   => 'text',   // varchar
        'length' => 3,
        'fill'   => true,

    ],
    'field_title' => [

        'type'   => 'text',   // varchar
        'length' => 150,
        'fill'   => true,

    ],

    'field_description' => [

        'type'   => 'text',   // varchar
        'length' => 10000,
        'fill'   => true,

    ],

    'field_content' => [

        'type'   => 'text',   // varchar
        'length' => 10000,
        'fill'   => true,

    ],

    'field_user' => [

        'type'   => 'text', // varchar
        'length' => 50,
        'fill'     => true,

    ],

    'field_time' => [

        'type'   => 'text', // varchar
        'length' => 50,
        'fill'     => true,

    ],

    'field_route' => [

        'type'   => 'text', // varchar
        'length' => 1000,
        'fill'     => true,

    ],

    'field_category' => [

        'type'   => 'bignum', // big int
        'length' => 255,
        'fill'     => true,

    ],

    'field_published' => [

        'type'   => 'num', // big int
        'length' => 1,
        'fill'   => null,

    ],

    'field_mainpage' => [

        'type'   => 'num', // big int
        'length' => 1,
        'fill'   => null,

    ]   

];

$STRUCT_COMMENTS = [

    'field_id' => [

        'type'   => 'bignum', // big int
        'auto'   => true,     // auto increment
        'length' => 255,
        'value'  => 0

    ],

    'field_node_id' => [

        'type'   => 'bignum', // big int
        'length' => 255,
        'fill'     => true

    ],

    'field_user_id' => [

        'type'   => 'bignum', // big int
        'length' => 255,
        'fill'     => true

    ],

    'field_country' => [

        'type'   => 'text', // varchar
        'length' => 3,
        'fill'   => true

    ],

    'field_user_name' => [

        'type'   => 'text', // varchar
        'length' => 100,
        'fill'     => true

    ],

    'field_content' => [

        'type'   => 'text', // varchar
        'length' => 10000,
        'fill'   => true

    ],

    'field_time' => [

        'type'   => 'text', // varchar
        'length' => 100,
        'fill'     => true

    ],

    'field_published' => [

        'type'      => 'num', // int
        'length' => 1,
        'fill'     => null

    ]

];
    $cFields = ['field_id', 'field_node_id', 'field_user_id', 'field_user_name', 'field_content', 'field_time', 'field_published','field_country'];
    $nFields = ['field_id', 'field_title', 'field_content', 'field_description', 'field_user', 'field_time', 'field_route', 'field_category', 'field_published', 'field_mainpage', 'field_country'];

    $nFields['criterion_table'] = 'revolver__nodes';
    $nFields['linked_table'] = 'revolver__comments';

    $nFields['criterion_field'] = 'field_id';
    $nFields['linked_field'] = 'field_node_id';

    $ncFields = [
        $cFields,
        $nFields
    ];
        
    $dbx::query('j', 'revolver__nodes|revolver__comments', $ncFields);

    $comments = $dbx::$result['result'];

 

[fixxxer]

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

В качестве массивов можно представить только read models. Entities (которые одновременно еще и write models) содержат прежде всего реализацию бизнес-логики; поля - это лишь внутреннее состояние сущности. Конечно, вместо полей можно сделать private array $properties, это особо ничего не меняет. Важно, где реализация бизнес-логики.

ООП тут важно как образ мышления, а не как ключевые слова языка программирования: можно написать объектную программу на C, следуя определенным соглашениям (например, так устроены модули в nginx).

Объекты тоже изначально на строках написаны и работает все до сих пор на единицах и нолях

Написать программу, которая понятна компьютеру, легко. Намного сложнее написать программу, которая понятна человеку, и останется таковой через 10 лет ее развития.

 

[Full-R]

Модель - это не то, что работает с базой данных (это популярное заблуждение).

Естественно. То есть это какие-то фрагменты для сборки чего-то походящего на реальное? Имея детали конструктора и связывающе элементы собирается модель.

Модель - это в целом слой, реализующий бизнес-логику, а конкретные классы (entities) моделируют определенные сущности предметной области на языке программирования.

При чем здесь слово бизнес?

В качестве массивов можно представить только read models. Entities (которые одновременно еще и write models) содержат прежде всего реализацию бизнес-логики; поля - это лишь внутреннее состояние сущности. Конечно, вместо полей можно сделать private array $properties, это особо ничего не меняет. Важно, где реализация бизнес-логики.

Какой логики? Если заглянуть глубже, куда-то в ядро, над вами бы серьезно посмеялись из-за слова бизнес, которое это ядро обслуживает, но такую терминологию не использует вообще.

ООП тут важно как образ мышления, а не как ключевые слова языка программирования: можно написать объектную программу на C, следуя определенным соглашениям.

А что есть ООП для вас? Сколько типов объектов вы видели в PHP и какой именно используете для доступа? Сам класс предлагаю не считать объектом потому, что private и protected недоступны извне.

Написать программу, которая понятна компьютеру, легко. Намного сложнее написать программу, которая понятна человеку, и останется таковой через 10 лет ее развития.

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

 

[Фанат]

Кость, мне кажется ему надо объяснять в контексте его велосипеда, на пальцах, ближе к его массивам, а то иначе он не поймёт.
А тебя относит к скорее обобщениям в контексте исходной темы.

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

 

[fixxxer]

При чем здесь слово бизнес?

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

Какой логики?

Логики предметной области. Если, например, взять игру в шахматы, то логикой предметной области будут правила игры в шахматы. Логика хранения ходов в базе данных, или логика отрисовки пользовательского интерфейса, или логика обмена информацией с клиентом для iPhone - это уже не логика предметной области.

А что есть ООП для вас?

Это когда программа состоит из объектов, обменивающихся сообщениями в соответствии с контрактами.
В Java-подобных языках обмен сообщениями реализуется вызовом методов, а контракт - это совокупность сигнатур методов данного типа (класса или интерфейса).

Заметим, что если взять С++-ное определение и сравнить с ним, то инкапсуляция тут есть ("снаружи" мы не знаем про объект ничего, кроме того, что он поддерживает контракт; его внутреннее состояние - его личное дело), полиморфизм есть (за контрактом может стоять сколько угодно его реализаций), а наследования нет.

 

[Full-R]

Познавательно.

Я наверное из другой сферы человек. Я на этих менеджерах по продажам систему отрабатывать не смогу и никто из моих знакомых для этого бизнес не использует. Читаю вас и навеяло воспоминаний года про 70е-80е. ARPa, бум на компьютеры, прелые пра-задницы вроде Бернса ... Intel, который заталкивает в прослушку города чтобы разработать предсказание ветвлений ... Щас так никто не делает - это просто помошники разработчиков(подумайте, что будет с бизнесом и какие там сроки за это).

 

[Фанат]

$dbx::query('j', 'revolver__nodes|revolver__comments', $ncFields);
$comments = $dbx::$result['result'];

Я здесь вижу как миниум одну проблему.
У объекта $dbx есть состояние, привязанное к конкретному запросу.
при первой же попытке выполнить второй запрос не завершив выборку данных из первого, система встанет колом.
У каждого запроса должен быть свой объект - как это сделано в пхп. Результат запроса лежит не в mysqli, а в mysqli_result.
У тебя должно быть так же.
(Это я со своей низенькой колокольни смотрю на конкретный кусок кода в своей IDE)

 

[Full-R]

Это для запросов :query(). Есть helper класс, который делает просто get() и в нем реализовано авто unset(
$dbx::$result['result'] ) перед получением; Это как Store Result только в памяти. А так перезапишет просто.

Колом ни чего не встало: SQL Qeries: {11} \ Cache Queries: {6}

После Store в ['result'] соединение с БД закроется сразу и весь инстанс анулируется.

Так хранить ненужно, как у вас написано.

 

[Фанат]

Соединение с БД закроется

В смысле? На каждый запрос новое соединение открывается? А зачем?
И как быть с транзакциями?

 

[Full-R]

У меня нет транзакций. Я создаю подготовленный запрос и там может быть не один SQL. Если не закрыть соединение - будет тратится память. Это то же что и доступ handler к файлу. Но файл у вас на локальной ФС, а подключение к серверу БД затрагивает еще больше ресурсов.

Может быть запрос ALTER. Это describe потом модификация и сверка. Три запроса - один коннект.

Ну и кэш: вообще без подключения к БД показывает данные.

Про транзакции. Я решил взять savepoints и не взять PDO. Транзакции это то же самое что и UNION на несколько SQL, а затем посыл на сервер с возможностью отката. Это мне не нужно.

Я пока не сделал обновление данных в статитке кэша и стек SQL, которые нужно закомитить на сервер, когда connection появится. Но работаю над этим.
То есть, пока сервер обновляется я могу спокойно писать и реадктировать контент, а как БД включится - просто коммит, где UNION цепочка из действий.

Транзакции ценны только в случае с rollback, а rollback не нужен никому.

 

[Фанат]

В общем да. Чувак явно не под деревом и не под Москвой.

 

[fixxxer]

Познавательно.

Я наверное из другой сферы человек.[..]

Что-то куда-то далеко понесло.
Разделение чистой логики предметной области и инфраструктурной логики дает необходимую гибкость в условиях постоянно меняющихся требований (а любое развитие связано с изменением требований, очень мало таких областей, когда требования можно отлить в камне навеки).

Это работает не только для задач автоматизации бизнеса. Если я, скажем, пишу SQL-совместимую РСУБД, то предметная область будет описана стандартом ANSI SQL, и в практически в любой вменяемо спроектированной РСУБД есть отдельный слой, преобразующий SQL во внутреннее представление запроса, удобное конкретному движку. В том же MySQL в частности именно поэтому так легко подключать различные движки для DQL/DML. И именно из-за того, что в свое время сделали архитектурную ошибку, прибив гвоздями системные словари к конкретному движку MyISAM, реализовать атомарный DDL смогли только в Mysql 8 после огромного рефакторинга.

 

[Full-R]

А еще можно упороться и написать процедуру для автослива БД на каждый change используя движки Federated и MyISAM, если админ нечаянно не настроил firewall для сервера БД на исходящие подключения ... Даже shell коды не нужны. Годами можно получать бесплатно кредитные истории, штрафы ГИБДД, картотеки, прочее ...

 

[WMix]

атомарный DDL смогли только в Mysql 8

alter table с откатом?

 

[Фанат]

Если он даже про шахматы не понял, то с SQL ты его вообще в бесконечный цикл вгонишь.
Напишет что-то вроде "SQL - это позапрошлый век, это то же самое что булева логика, только реализованная в виде демона."

 

[Full-R]

Восстанавливать данные по savepoint я не реализовал. А структуру если поменялись типы полей вернуть не сложно. Вот если вы сбросили столбец, то и данные исчезли. Я сам и front-end и backend пишу, а еще нужен дизайн и анимации. Мне на все времени не хватает, но, когда нибудь я и это сделаю. Слолбцы сдампить не долго перед модификацией.

 

[fixxxer]

alter table с откатом?

В 8-ке то? В некотором смысле.
Если единый alter table с кучей всякого обломается посередине, то все откатится.
С явными транзакциями (begin/commit/rollback) пока что не работает. Технически там уже все есть для того, чтобы это сделать, если внутри транзакции будут ТОЛЬКО DDL инструкции. А вот со смесью пока проблема (у DDL свой отдельный лог, и надо все это дело еще совместить).