Umbrüche und Tabs in Queries, guter Stil

[thommyk]

ist es eigentlich schlechter Stil, wenn in meinen queries Umbrüche und Tabulatoren vorkommen, bedingt durch den Editor

also so :

$query = "/*REGIONSIDEPORT*/ CREATE TABLE IF NOT EXISTS `$mySQLDatabase_portal`.`portal_region_sides` ( 
    `locationID` varchar(9) character set latin1 collate latin1_bin NOT NULL default '', 
    `portalID` tinyint(4) NOT NULL default '0', 
    `sideNumber` int(11) NOT NULL default '0', 
    `objectNumber` varchar(8) NOT NULL default '', 
    KEY `objectNumber` (`objectNumber`), 
    KEY `locationID` (`locationID`,`portalID`,`sideNumber`), 
    KEY `portalID` (`objectNumber`) 
    ) ENGINE=MyISAM DEFAULT CHARSET=latin1"; 

Oder ist es besser so:

$query = "/*REGIONSIDEPORT*/ CREATE TABLE IF NOT EXISTS `$mySQLDatabase_portal`.`portal_region_sides` ( "
    ."`locationID` varchar(9) character set latin1 collate latin1_bin NOT NULL default '', "
    ."`portalID` tinyint(4) NOT NULL default '0', "
    ."`sideNumber` int(11) NOT NULL default '0', "
    ."`objectNumber` varchar(8) NOT NULL default '', "
    ."KEY `objectNumber` (`objectNumber`), "
    ."KEY `locationID` (`locationID`,`portalID`,`sideNumber`), "
    ."KEY `portalID` (`objectNumber`) "
    .") ENGINE=MyISAM DEFAULT CHARSET=latin1"; 

Ich halte mich an die 2. Version, mein Chef hätte lieber die 1., da man dann die Abfrage leichter im phpMyAdmin einfügen kann, meint er, womit er ja auch recht hat.
Ich möchte aber gerne alle überflüssigen Zeichen aus der query raushalten.
Was sagen die SQL-Experten?

[wahsaga]

Der DB-Engine ist das völlig egal.

[onemorenerd]

Das Argument deines Chefs ist überzeugend. Dein Argument mit den zusätzlichen Zeichen in der Query ist es nicht, denn die paar Zeichen kosten doch nichts. Klar, sie müssen zum DBS übertragen und dort beim Parsen der Query mit verarbeitet werden. Aber das fällt nicht ins Gewicht und vor allem muss man dem ja entgegen stellen, dass der PHP-Parser die Stringverkettung auch erstmal parsen muss.

Ganz schlimm wird es übrigens, wenn der Programmierer die Tabellen- und Spaltenbezeichner bis zur Unkenntlichkeit verkürzt um Zeichen zu sparen. Da wird dann eindeutig an der falschen Stelle optimiert.

Nochwas: Benutzt doch einfach mal eine ordentliche DB-Abstraktion.

[thommyk]

danke

Danke. Der einzige Nachteil, der mir einfällt, ist dieser:
Wir haben ein tool names mysqldWatcher.pl im Einsatz, das alle zu lang laufenden Abfragen killt, um zu verhindern, dass eine schlechte Abfrage viele andere blockiert. Das Skript hatte aber Probleme mit tabulatoren und Umbrüchen.
Allerdings sollte man eher seine Queries optimieren, damit sowas nicht nötig ist.

Benutzt doch einfach mal eine ordentliche DB-Abstraktion

Was meinst Du damit? Worauf bezieht sich das?

[combie]

DB-Abstraktion
Was meinst Du damit? Worauf bezieht sich das?

Vermutlich sowas wie propel oder doctrine.
Also ein ORM .

[thommyk]

never heard of, aber danke. Man lernt nie aus.

[onemorenerd]

Was meinst Du damit? Worauf bezieht sich das?

Es gibt DB-Abstraktionen, bei denen man überhaupt kein SQL mehr formuliert. Man hantiert mit Objekten, ruft Methoden auf und sagt irgendwann execute(). In dem Moment wird von der Abstraktionsschicht aus den Objektzuständen SQL erzeugt. Das kann man sich dann auch mal ansehen - notfalls überschreibt man eine Klasse und ergänzt eine entsprechende Debug-Methode. Dort hat man dann die Freiheit, zu formatieren wie man möchte. Dein Chef kann einen anderen Formatter wählen als du. Problem gelöst.