Adminer – a lightweight alternative to PhpMyAdmin

PhpMyAdmin is powerfull but the GUI is messy. Adminer is a lightweight alternative. You have to download the files and place them in your folder.


# sudo apt-get isntall adminer
# sudo ln -s /usr/share/adminer/ adminer

The first line will install the files. They are saved in /usr/share/adminer. Therefore we need a symbolic link to the folder, which is made in the second line of code.

SQL count(): The Most Popular Cake

So how do yo find the most popular cake in the Shire Bakery? Here’s an idea.

PhpMyAdmin: the most popular caske
PhpMyAdmin: the most popular caske
-- Show the best cookie
-- See: Ben Forta Chap. 16
SELECT COUNT( cakes.cake ) AS 'popular', cakes.cake, costumers.who
FROM cakes, costumers, likes
-- sort out the cardinalities (relations)
WHERE cakes.cakes_id = likes.cakes_id
AND costumers.costumers_id = likes.costumers_id

-- group by the cake 
group by cakes.cake

-- and sort (most popular and downwards)
order by popular desc

SQL: Many-to-Many and One-to-Many

Here’s a short tutorial on how to solve some basic SQL cardinalities. First have a look at the ER-diagram for the database and the resulting tables in PhpMyAdmin.

Many to many and one to many
Many to many and one to many
The ER-Diagram transformed to tables in PhpMyAdmin
The ER-Diagram transformed to tables in PhpMyAdmin

Many-to-Many

Many to many cardinalities may be solved like this:


SELECT cake, who
FROM cakes, costumers, likes
WHERE costumers.costumers_id = likes.costumers_id
AND cakes.cakes_id = likes.cakes_id

Note that there are two where clauses combined via AND.

One-to-Many

This cardinality is more easy:


SELECT inventory .* , costumers.who
FROM inventory, costumers
WHERE inventory.costumers_id = costumers.costumers_id

In the “many” table you simply connect via the “one” table’s id.

You can download and try out the samples from my Github Repository oneToMany_ManyToMany.

Read On

These samples are inspired by Ben Forta’s “MySQL Crash Course” Ch. 15 – 16.

CSS i plugin

Dokumentationen på Codex er ikke lysende klar; men et plugin gør sådan:

/* filters etc. */
add_action('wp_print_styles', 'add_hyperboard_stylesheet');

// (...)

/*Required stylesheets */
function add_hyperboard_stylesheet() {
	$myStyleUrl = WP_PLUGIN_URL . '/hyperboard/styles.css';
	$myStyleFile = WP_PLUGIN_DIR . '/hyperboard/styles.css';

        if ( file_exists($myStyleFile) ) {
            wp_register_style('HyperBoardStyleSheets', $myStyleUrl);
            wp_enqueue_style( 'HyperBoardStyleSheets');
        }
}

Pluginet sætter en krog i wp_print_styles.

Ugens kode-“sprint”

Scrumologer ville sikkert tale om en uge-sprint. For sidste uge var en ekspedition ind i WordPress API. Nu ved jeg, hvordan man bruger databaser og menuer i et plugin.

– Har det været en nem rejse?

Næh. Folk der skriver kode er ikke altid gode til at forudse de problemer, som brugerne kan komme til at stå i. Vejledningen i at indsætte data i en database var ikke god i Codex. Eksemplerne tog ikke højde for en typisk situation: hvordan man indsætter data i en tabel, hvor fx Id autoincrementeres. Kapitlet om submenuer var heller ikke soleklart.

Men når det er sagt, så er det rart, at det ER-diagram, som blev tegnet omkring jul nu er ved at blive en database, der faktisk ser ud til at fungere i praksis. Jeg blev ikke helt færdig med prototypen; men dog færdig nok til at se, at koden nok skal virke.

Med reference til Scneidermann er jeg så småt ved at arbejde med vejledende tekster. Menuen og undersiderne fremkaldes i disse dage. Så dette sprint ender med at jeg har en kode, der sikkert vil virke. Jeg har i hvert fald noget, der kan noget. Og det er lissom derhen scrumologerne vil age.