[thesecondjoker]

hi leuts,

hab mal ne kurze frage. ich möchte gerne meine php-seiten noch viel dynamischer machen (eigentlich eher dynamisch als dynamischer). hierzu habe ich heute meine db-abfrage komplett überarbeitet und zwar so, dass ich dies quasi in jedes script einbauen kann und nur noch ne variable für die db-tabelle angeben muss.
früher habe ich zusätzlich noch die einzelnen spaltennamen und den primärschlüssel der tabelle von hand angeben müssen. nun kann ich mir den kram sparen, allerdings habe ich probleme die spalte mir dem primärschlüssel dynamisch herauszufinden. ich weiss nicht genau wie. des weiteren hatte ich in meinem formular ein hidden-feld, welches die id des tupels enthielt, so wurde beim post die id übergeben um z.b. zu bearbeiten oder zu löschen.

ich habe bereits die funktionsreferenz von php durchgesucht, aber nichts brauchbares gefunden. bin ein bissl ratlos...

pls help...


greets
tsj

[WarrenFaith]

allerdings habe ich probleme die spalte mir dem primärschlüssel dynamisch herauszufinden

Da normalerweise eine korrekte DB-Tabelle als Primärschlüssel die Spalte ID oder id hat, sollte es kein Problem sein, diese zu erkennen. Bei Fremdschlüsseln würde es interessant werden.
Gib doch mal ne Beispieltabelle an, dann kann dir auch konkreter geholfen werden.
Und Hidden-Felder sollten tunlichst vermieden werden, da sie leicht zu mißbrauchen sind.

[thesecondjoker]

ich benenne zwar meine primärschlüssel immer auch xxxid, aber ich wüsste nu nicht wie mir das weiterhelfen soll, da ich keine platzhalter und php kenne.

eine tabelle wäre z.b.

CREATE TABLE Hersteller(
HerstellerID SERIAL NOT NULL PRIMARY KEY,
HerstellerName VARCHAR(50) NOT NULL);

Meine Tabell würde so aussehen

HerstellerID | HerstellerName | Optionen
--------------------------------------------
1 | ASUS | [hidden-feld mit HerstellerID] | Löschen

Hidden-Felder sollten tunlichst vermieden werden, da sie leicht zu mißbrauchen sind

das ist zwar richtig, doch erstens verwende ich natürlich post wodurch das fälschen schon mal schwieriger wird und zweitens ist das ganze unternehmensintern, sodass man sagen kann, die daus werden wohl nichts fälschen. ich könnte das zwar mit session-variablen machen, doch ich würde quasi den gleichen weg gehen müssen, oder?

[WarrenFaith]

1. Also alle Spaltennamen mit dem Tabellennamen zu versehen ist sinnlos. Tabelle Hersteller hat den Spalten Name, Tabelle Accounts hat auch ne Spalte Name und sie behindern sich nicht im geringsten dadurch. Du solltest also deine Namensgebung der Spalten überdenken

2. Lass keine Sicherheitslücke im Vertrauen auf die Dummheit/das Unwissen anderer

erstens verwende ich natürlich post wodurch das fälschen schon mal schwieriger wird und zweitens ist das ganze unternehmensintern

Du brauchst nur die Seite speichern und kannst jeden Wert beliebig bearbeiten. Denn deine Verarbeitung des Formulars erkennt nicht, ob die Seite von einer lokalen Adresse aus geöffnet wurde oder im Browser und es ist egal, ob dabei POST oder GET verwendet wird.
Ebenfalls sollten DAUs nicht unterschätzt werden. Ein DAU macht mehr falsch als ein Wissender und dadurch sind gerade diese "gefährlich".

[thesecondjoker]

ja gut...danke für den tipp! hab das mit dem tabellennamen zwar nicht ganz kapiert, habe aber mein problem selbst lösen können!

vielen dank!

[mepeisen]

Achja und noch ein Hinweis: Wenn das als eine Art Basisklasse oder Framework gedacht ist, ist der Weg, sowas auch mal im Internet einzusetzen nicht weit (beispielsweise auch in einer ganz anderen Webseite) und dann wird garantiert keiner mehr an die Sicherheitslücke mit den Hidden-Feldern denken und irgendwann schreits...

. Also alle Spaltennamen mit dem Tabellennamen zu versehen ist sinnlos. Tabelle Hersteller hat den Spalten Name, Tabelle Accounts hat auch ne Spalte Name und sie behindern sich nicht im geringsten dadurch. Du solltest also deine Namensgebung der Spalten überdenken

Als Sinnlos würde ich das nicht bezeichnen. Spätestens, wenn man Abfragen mit mehreren Tabellen hat, kann das sehr der Übersichlichkeit zugute kommen. Ich nutze bei meinen Tabellenspalten zwar selten den genauen Tabellennamen, jedoch bekommen alle Tabellen einen zum Tabellennamen artverwandten String vorgestellt.
...hat sich bewährt.

[WarrenFaith]

?
Wozu gibts dann bitte den Tabellenname.Spaltenname konstrukt?
Wenn ich 2 Tabellen in eine Abfrage einbaue:

SELECT Tabelle1.ID AS T1_ID, Tabelle2.ID AS T2_ID FROM Tabelle1 INNER JOIN Tabelle2 ON Tabelle1.Tabelle2_ID = Tabelle2.ID;

Außerdem sind dynamische Tabellennamen schonmal ganz schlecht anwendbar.
Und wenn man später mal eine Tabelle namentlich ändern will muss jede Spalte bearbeitet werden.
Also ganz im Sinne des Erfinders ist sowas nicht...

Hm, vielleicht laufen wir auch gerade ein wenig aneinander vorbei mit unseren Meinungen.
Ich sage ja, dass ich nicht immer den originalnamen der Tabelle vor die Spaltennamen lege. Wenn ich jedoch z.B eine Tabelle habe, wo Ausgaben aus meheren Tabellen ausgeggeben werden, erleichertert es oft die Wartung, wenn ich dann so etwas wie: $res[herstellerID]
in der Tabelle stehen habe.
Gerade auch, wenn man fremden Code warten oder auch nur verstehen muss/will.
So sieht man sofort, welcher Tabelle die Ausgabe zugeordnet ist. Ob die Tabelle dabei auch HERSTELLER, oder tbl_hersteller oder auch ICHbinEINhersteller heisst, ist dabei nicht so wichtig. Er kann also durchaus umgeändert werden. Wichtig ist nur, dass der Zusammenhang besteht.
Eine Tabelle, welche Herstellerdaten enthält, wird ja nun auch nimand in "tbl_rosa_plueschbaellchen" umbenennen wollen.

Ich hoffe, ich habe nun besser rübergebracht, was ich sagen wollte.

grüsse
flupsi

[WarrenFaith]

Du redest von Fremdschlüsseln, da geb ich dir recht. Hersteller_ID wäre dahingehen korrekt.
Problem von thesecondjoker war aber, dass er selbst seine Primärschlüssel nicht nur ID genannt hat. Er hat ja den kompletten Tabellennamen vor die Spaltennamen gelegt, was totaler unsinn ist.

akzeptiert