ebiz-webhosting
- Ad -
php-resource



Zurück   PHP-Scripte PHP-Tutorials PHP-Jobs und vieles mehr > Scripts > BRAINSTORMING PHP/SQL/HTML/JS/CSS
 

Login

 
eingeloggt bleiben
star Jetzt registrieren   star Passwort vergessen
 

 

 


BRAINSTORMING PHP/SQL/HTML/JS/CSS Ihr habt eine Idee, aber keinen genauen Ansatz? Diskutiert mit anderen Usern des Forums über eure Gedankengänge um evtl. hilfreiche Ideen zu bekommen!
Normale Fragen bitte weiterhin in die entsprechenden Foren!

Antwort
 
LinkBack Themen-Optionen Thema bewerten
  #1 (permalink)  
Alt 23-10-2017, 10:55
SysOp
 Registrierter Benutzer
Links : Onlinestatus : SysOp ist offline
Registriert seit: May 2005
Beiträge: 54
SysOp befindet sich auf einem aufstrebenden Ast
Standard Grundsatzdiskussion SELECT *

Was an SELECT * soll denn nun so grundlegend falsch sein? Mir erschliesst sich nicht wieso SELECT * solch Teufelswerk sein soll.

Anlass meiner Frage ist die Tatsache, dass in einem Thread wieder einmal mehr darauf hingewiesen wurde, wie schlimm SELECT * nicht sei, ohne überhaupt zu wissen, ob z.B. die Notwendigkeit, alle Felder zu lesen, besteht oder nicht. Ob und wie die Ergebnisse dann verifiziert werden war dem Beispiel auch nicht zu entnehmen.
Auffällig war jedenfalls der Hinweis, dass SELECT * sogar falsch sei und das lese ich nicht zum ersten mal!

Bsp.
Ich erlaube dem Admin in nahezu allen meinen Projekten selbst Felder in der Datenbank zu definieren. Meistens fehlen ja wirklich irgend welche Felder, die man dringend benötigen würde.
Da ich dem Anwender ersparen möchte für jedes selbst definierte Feld selbst Hand an den Code legen zu müssen, damit seine Felder auch ausgelesen werden ist ein SELECT * eine ebenso einfache wie unproblematisch funktionierende Abfrage.
Natürlich könnte ich nun jedes Mal den Aufbau einer Tabelle auslesen, den SELECT danach der Reihe nach abarbeiten und im Script mit den Feldnamen Schritt für Schritt zusammenbauen. Tatsächlich macht der Code dann aber auch nichts anderes als ein SELECT *, er wäre nur länger, fehleranfälliger und schlechter lesbar.

Aus reiner Ressourcen-Schonerei (sollte das der Grund sein) macht das Vermeiden eines SELECT * auch keinen wirklichen Sinn.
Im 21`sten Jhd und bei der Performance der aktuellen Server sind Laufzeitdifferenzen im Hunderstel Bereich nichts, was einen merkbaren Unterschied machen würde. Dann müsste ich genauso aus Ressource-Gründen Objekte verteufeln.

Den Grund für einen prinzipiellen Horror, beim Anblick von SELECT * sehe ich einfach nicht.
Mit Zitat antworten
  #2 (permalink)  
Alt 23-10-2017, 12:18
h3ll
 Registrierter Benutzer
Links : Onlinestatus : h3ll ist offline
Registriert seit: Mar 2008
Beiträge: 3.485
h3ll befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
Zitat von SysOp Beitrag anzeigen
Was an SELECT * soll denn nun so grundlegend falsch sein? Mir erschliesst sich nicht wieso SELECT * solch Teufelswerk sein soll.
1. Unvorhersehbares Ergebnis.

2. Schlecht lesbarer Code.

3. Mögliche Performance-Probleme.

4. Mögliche Fehler, die dann nicht auffallen.

Zitat:
Zitat von SysOp Beitrag anzeigen
Ich erlaube dem Admin in nahezu allen meinen Projekten selbst Felder in der Datenbank zu definieren.
Hier muss man zwischen Serveradmin und Anwendungsadmin unterscheiden.

Ein Serveradmin interessiert sich nicht für Spalten der Anwendung.

Ein Anwendungsadmin hat in der Datenbank nichts verloren. Für den stellt die Anwendung eine Administrationsoberfläche zur Verfügung. Und hier werden natürlich keine Spalten angelegt. Denn zur Laufzeit sollte die Datenbank nicht verändert werden.


Zitat:
Zitat von SysOp Beitrag anzeigen
Meistens fehlen ja wirklich irgend welche Felder, die man dringend benötigen würde.
Da ich dem Anwender ersparen möchte für jedes selbst definierte Feld selbst Hand an den Code legen zu müssen, damit seine Felder auch ausgelesen werden ist ein SELECT * eine ebenso einfache wie unproblematisch funktionierende Abfrage.
Ein Anwender legt keine Spalten in der Datenbank an. Wenn das so ist, liegt ein Fehldesign der Anwendung vor.

Zitat:
Zitat von SysOp Beitrag anzeigen
Den Grund für einen prinzipiellen Horror, beim Anblick von SELECT * sehe ich einfach nicht.
Ich sehe, dass du offenbar ein Fehldesign mit einem SELECT * umgehen willst. Dann noch ein Negativpunkt für SELECT *: Es ermöglicht/bestärkt so eine falsche Vorgehensweise.
Mit Zitat antworten
  #3 (permalink)  
Alt 23-10-2017, 22:46
Benutzerbild von mermshaus mermshaus
 Registrierter Benutzer
Links : Onlinestatus : mermshaus ist offline
Registriert seit: Jun 2009
Beiträge: 449
mermshaus wird schon bald berühmt werden
Standard

Ich würde das Pferd umgekehrt aufzäumen und fragen, worin der Vorteil von SELECT * besteht.

Es mag situative Anwendungen dafür geben, die meinetwegen auch einsichtig sind, aber ich möchte die These in den Raum stellen, dass ein DB-Schema häufig aus Anwendungssicht doch eher starr ist, weil nicht selten eine Menge Logik sehr eng damit verknüpft ist. Mit Änderungen am DB-Schema sind häufig auch Anpassungen in der Anwendung verbunden, weil etwa Models nach dem DB-Schema angelegt sind und dergleichen.

In solchen Fällen mag SELECT * Schreibarbeit sparen, aber das geht sehr unmittelbar auf Kosten der Nachvollziehbarkeit, weil Felder dann schnell auf magische Weise mit Werten gefüllt werden und etwaige Probleme (neues Feld nicht korrekt durchimplementiert) dadurch verdeckt werden könnten.

Man erzeugt damit einen kognitiven Mehraufwand, weil man es gewissermaßen verhindert, dass das DBMS beim Auslesen gewünschter Felder etwaige Oversights automatisch anmerkt.

Ich würde es vielleicht auch mit INSERT-Queries vergleichen, bei denen man in der Regel auch nicht mit dynamischen/variablen Feldlisten arbeitet.

Geändert von mermshaus (24-10-2017 um 10:49 Uhr)
Mit Zitat antworten
  #4 (permalink)  
Alt 25-10-2017, 15:46
Benutzerbild von fireweasel fireweasel
 Registrierter Benutzer
Links : Onlinestatus : fireweasel ist offline
Registriert seit: Sep 2008
Ort: At home
Beiträge: 843
fireweasel wird schon bald berühmt werdenfireweasel wird schon bald berühmt werden
fireweasel eine Nachricht über AIM schicken fireweasel eine Nachricht über Yahoo! schicken
Standard

Zitat:
Zitat von SysOp Beitrag anzeigen
Was an SELECT * soll denn nun so grundlegend falsch sein? Mir erschliesst sich nicht wieso SELECT * solch Teufelswerk sein soll.
Ist es nicht. Es hat sicher seinen Anwendungsbereich. Aber den sollte man besser beschränken (bspw. aufs interaktive Herumprobieren in der Konsolen-Anwendung des Clients).
Zitat:
Da ich dem Anwender ersparen möchte für jedes selbst definierte Feld selbst Hand an den Code legen zu müssen, damit seine Felder auch ausgelesen werden ist ein SELECT * eine ebenso einfache wie unproblematisch funktionierende Abfrage.
Du sparst einmalig (beim Entwurf einer Abfrage) etwas Tipparbeit. Das klingt eher nach Faulheit als nach Einfachheit.

Unproblematisch (in Bezug auf Funktionssicherheit) ist deine SELECT-Anweisung nur, solange sich nichts am Datenbankaufbau oder im Anfrage-Teil nach FROM ändert. Was konkret schiefgehen kann, steht hier geschrieben: https://softwareengineering.stackexc...ractice/234678
Relevante Abschnitte sind "Schema Changes" und "Failure to convey intent".

Für den Fall, dass ausgelesene Datensätze in ein assoziatives Array wandern, hat PHP hat noch eine Extra-Stolperfalle eingebaut: https://softwareengineering.stackexc.../234667#234667

Dass SELECT * auch die Datenbank davon abhalten kann, Indizes zu nutzen, fällt dann auch nicht mehr ins Gewicht.

Geändert von fireweasel (25-10-2017 um 15:48 Uhr) Grund: typo
Mit Zitat antworten
Antwort

Lesezeichen


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 

Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
DropDown: 3. Select abhängig von 1. & 2. Select e_allora HTML, JavaScript, AJAX, jQuery, CSS, Bootstrap, LESS 0 04-09-2015 15:46
[MySQL Query] IF($var == true) SELECT... ELSE SELECT... fuerto SQL / Datenbanken 1 12-12-2013 14:56
[gelöst] Alias aus SELECT wieder in SELECT verwendet dumdumdum SQL / Datenbanken 6 21-09-2009 18:05
Grundsatzdiskussion links und listen Kropff Off-Topic Diskussionen 17 18-05-2006 17:01
[JavaScript] Select 1 darf nicht größer sein als Select 2, wie anstellen? Bang HTML, JavaScript, AJAX, jQuery, CSS, Bootstrap, LESS 6 16-06-2004 13:03

Themen-Optionen
Thema bewerten
Thema bewerten:

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are an


PHP News

Mit Web-Templates Geld verdienen
Mit Web-Templates Geld verdienenWeb-Templates gewinnen immer mehr an Bedeutung. Erfahre hier, wie du dir mit dem TemplateMonster-Marktplatz neue Verkaufswege erschließen kannst.

17.10.2017 | Berni

Kostenloser PHP Editor Codelobster
Kostenloser PHP Editor CodelobsterEin einfach zu verwendender PHP, HTML, CSS, JavaScript Editor mit vielen Funktionen

21.09.2017 | Berni


 

Aktuelle PHP Scripte

PHP Newsletter Script SuperWebMailer ansehen PHP Newsletter Script SuperWebMailer

Die webbasierte PHP Newsletter Software SuperWebMailer ist die optimale Lösung zur Durchführung eines erfolgreichen E-Mail-Marketings. Zur Nutzung des PHP Script-Pakets ist eine eigene Webpräsenz/Server mit PHP 4 oder neuer, MySQL 3.23 oder neuer und die

17.11.2017 mirko_swm | Kategorie: PHP/ Mail
belbit Ticketcenter ansehen belbit Ticketcenter

Supportanfragen per Helpdesk über E-Mail und per Kontaktformular entgegennehmen. Inkl. iPhone- und Android App zum mobilen Beantworten von Anfragen.

14.11.2017 EichbaumMedia | Kategorie: PHP/ Ticketsystem
PHP Counter Script V1.0 ansehen PHP Counter Script V1.0

Ein ganz einfach einzubauender Besucherzähler. Kostenlos und ohne Werbung für private und gewerbliche Webseiten!

14.11.2017 hinnendahl_com | Kategorie: PHP/ Counter
 Alle PHP Scripte anzeigen

Alle Zeitangaben in WEZ +2. Es ist jetzt 03:52 Uhr.