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, 09:55
SysOp
 Registrierter Benutzer
Links : Onlinestatus : SysOp ist offline
Registriert seit: May 2005
Beiträge: 67
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, 11:18
h3ll
 Registrierter Benutzer
Links : Onlinestatus : h3ll ist offline
Registriert seit: Mar 2008
Beiträge: 3.578
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, 21:46
Benutzerbild von mermshaus mermshaus
 Registrierter Benutzer
Links : Onlinestatus : mermshaus ist offline
Registriert seit: Jun 2009
Beiträge: 451
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 09:49 Uhr)
Mit Zitat antworten
  #4 (permalink)  
Alt 25-10-2017, 14:46
Benutzerbild von fireweasel fireweasel
 Registrierter Benutzer
Links : Onlinestatus : fireweasel ist offline
Registriert seit: Sep 2008
Ort: At home
Beiträge: 851
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 14: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 14:46
[MySQL Query] IF($var == true) SELECT... ELSE SELECT... fuerto SQL / Datenbanken 1 12-12-2013 13:56
[gelöst] Alias aus SELECT wieder in SELECT verwendet dumdumdum SQL / Datenbanken 6 21-09-2009 17:05
Grundsatzdiskussion links und listen Kropff Off-Topic Diskussionen 17 18-05-2006 16: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 12: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

ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlicht
ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlichtDie bekannte Marktplatzsoftware ebiz-trader ist in der Version 7.5.0 veröffentlicht worden.

28.05.2018 | Berni

Wissensbestand in Unternehmen
Wissensbestand in UnternehmenLebenslanges Lernen und Weiterbilden sichert Wissensbestand in Unternehmen

25.05.2018 | Berni


 

Aktuelle PHP Scripte

PHP Server Monitor

PHP Server Monitor ist ein Skript, das prüft, ob Ihre Websites und Server betriebsbereit sind.

11.09.2018 Berni | Kategorie: PHP/ Security
PHP WEB STATISTIK ansehen PHP WEB STATISTIK

Die PHP Web Statistik bietet Ihnen ein einfach zu konfigurierendes Script zur Aufzeichnung und grafischen und textuellen Auswertung der Besuchern Ihrer Webseite. Folgende zeitlichen Module sind verfügbar: Jahr, Monat, Tag, Wochentag, Stunde Folgende son

28.08.2018 phpwebstat | Kategorie: PHP/ Counter
Affilinator - Affilinet XML Produktlisten Skript

Die Affilinator Affilinet XML Edition ist ein vollautomatisches Skript zum einlesen und darstellen der Affili.net (Partnerprogramm Netzwerk) Produktlisten und Produktdaten. Im Grunde gibt der Webmaster seine Affilinet PartnerID ein und hat dann unmittelb

27.08.2018 freefrank@ | Kategorie: PHP/ Partnerprogramme
 Alle PHP Scripte anzeigen

Alle Zeitangaben in WEZ +2. Es ist jetzt 17:12 Uhr.