Working examples of various technologies and practices - Docker, JSON API, Vue2, laravel8, Phoenix/Elixir, Webpack.
- Copy the
.env.example
to.env
. - Open
.env
and fill values inFILL_THIS
.
./setup.sh
172.60.2.10 ruu.local
172.60.2.11 api.ruu.local
172.60.2.14 pma.ruu.local
By using less framework specific methods and more language-wide features makes a migration to other language, framework or version, less complex.
like schemor builders, seeders, ORM, or self-defined logic inside a Model.
Less space for side-effects.
if the project is moved to other language, framework or version.
The choise to use RAW queries comes from a harsh experience.
Once worked in a project where migrations were written in the regular way - using ORM and methods defined in database models. Problems arise after a long code refactoring. Migration didn't work because the logic in the code has changed!
The migrations needs to be made incrementaly - step by step. It is easier to copy RAW queries in specific steps, than trying to convert the code to the specific SQL.
In raw queries it will happen as defined and the refactor migrations will incrementaly updated databases.
Up to you. Just be consistent though.
- Table Naming Dilemma: Singular vs. Plural Names [closed] (stackoverflow.com)
- Plural vs Singular Table Name (dba.stackexchange.com)
- The table naming dilemma: singular vs. plural (medium.com/@fbnlsr)
- Use singular nouns for database table names (teamten.com)
- dzhim-cms/fmw/core/Autoload.php
- This approach comes from a project where an object files, classes, tables needed to be generated from a variable. It is easier to handle a singular word than plural. Example, man -> mans (incorrect but works), men on the other hand is harder to convert to singular without adding a new value.
- Mostly table names are shorter. Good when have a lot of relation tables.
public static function updatePrice(int $productId)
{
return \DB::statement("
UPDATE `product`
SET `price` = (SELECT SUM(price) FROM ingredient WHERE `product_id` = ? AND deleted_at IS NULL)
WHERE `id` = ?
", [$productId, $productId]);
}
This query's execution is way faster and stable when called in SQL rather than in PHP (collect items, calculate and set).
public static function updateSeq(int $productId)
{
return \DB::statement("
UPDATE `ingredient`
SET `seq` = (@i := @i+1)
WHERE `product_id` = ?
AND `deleted_at` IS NULL
ORDER BY `seq` ASC
(SELECT @i := 1)
", [$productId]);
}
This query's execution is way faster and stable when called in SQL rather than in PHP (collect items, calculate and set).
Sometimes the abstraction just can't exactly implement the desired outcome which could lead to silly workarounds and make the code less maintainable.