[Erledigt] nächste autoincrement ID aus verschiedene Tabellen ermitteln

Hi,

ich benötige eine Abfrage, die mir die nächste autoincrement-ID aus einer Tabelle holt.

Bisher hat mir folgende Abfarge gute Dienste geleistet:

$id = mysql_fetch_row( mysql_query( "SELECT MAX(id) + 1 FROM artikel")); 

Nun sitz ich aber daran, das Script umzuschreiben. Denn es gibt nun 2 verschiedene Tabellen, wo die Artikel gespeichert werden (abhängig davon, welche Artikelart es ist. Z.b. KFZ Artikel oder Lebensmittel.. etc.)

Ich würde es nun gern so machen, das ich selbst vorgebe, was die nächste ID ist. Das macht zwar autoincrement überflüssig.. aber so hab ich eine ArtikelID, die eindeutig einem Artikel zugeordnet ist.

So... folgende Abfrage liefert mir erstmal die Tabellen namen zurück, die ich gern abfragen möchte.

SELECT `tabellen_namen` FROM `verkaufsformular` WHERE `freigeschaltet` = 1

z.B.
tabellen_namen
     artikel-kfz
     artikel-lebensmittel

Nun hatte ich mir gedacht:

SELECT MAX(id) + 1 FROM (SELECT `tabellen_namen` FROM `verkaufsformular` WHERE `freigeschaltet` = 1)

Nur leider:

Every derived table must have its own alias

Die Fehlermeldung ist sicherlich richtig... aber nicht anwendbar (zumindest nicht mit der Sub-Select-Abfrage)

Wie kann ich es anders machen, sodas ich wirklich nur die höchste ID von der Sub-Select-Abfrage zurückbekomme.


Braucht Ihr die Tabellen-Struktur hierfür (?)

[nikosch]

Ich verstehe die Frage überhaupt nicht.

[noop]

2 verschiedene Datenbanken-Tabellen = Welche das sind, werden mir aus einer SELECT Anweisung zurückgegeben.

Aus diesen 2 Tabellen benötige ich die höchste Autoinc. ID.

Jetzt verständlicher ?

[nikosch]

Und was bedeutet dann

Ich würde es nun gern so machen, das ich selbst vorgebe, was die nächste ID ist. Das macht zwar autoincrement überflüssig.. aber so hab ich eine ArtikelID, die eindeutig einem Artikel zugeordnet ist.

Dass Auto_increment nachbauen Dir arge Probleme mit ID-Duplikaten bereiten kann, ist Dir aber schon klar, oder?

[Patrick Hilker]

Warum verwendest du zwei oder mehr Tabellen? Eine Tabelle für alle Artikel reicht völlig.

Tabelle 'artikel'

id | artikelname | kategorie_id
1 | brot | 1
2 | reifen | 2
3 | sitz | 2

Du könntest jetzt noch eine weitere Tabelle zur Verwaltung der Kategorien erstellen, es funktioniert aber auch ohne.

Tabelle 'kategorien'

id | name
1 | lebensmittel
2 | kfz

auto_increment selbst nachzubauen macht in meinen Augen keinen Sinn.

[noop]

Na bisher ist es so, das ID autoincrement ist.

Sprich ein INSERT erfolgt ohne ID, da diese ja fortlaufend von MYSQL vergeben wird.

Ich würde es nun aber gern so machen, das ich diese ID vorgebe.
Damit verhindere ich, das ich keine doppelt vergeben autoincrement ID habe.

Z.b.
Tabelle: artikel_kfz
ID: 123 Ölfilter

Tabelle: artikel_lebensmittel
ID: 123 Schokolade

Das wäre dann dumm, da später die ID: 123 für 2 mögliche Artikel einen Treffer liefern würde. z.B. Wenn der Besucher eine Artikelnummer sucht.

[noop]

[QUOTE=Patrick Hilker;533650]Warum verwendest du zwei oder mehr Tabellen? Eine Tabelle für alle Artikel reicht völlig.
[/CODE]

Falsche Mutmassung. Denn im Lebensmittelbereich gibt es so viele Spalten, das ich den Autoindex (oder wie immer der heißt) schon erreicht habe.

Sicherlich deshalb, weil ich mittels varchar(255) recht bedenkenlos damit umgegangen bin... aber selbst nach der Aktualisierung dürfte da nicht mehr viel frei sein, so das ich wohl mit weiteren Eiongabefeldern (die halt nur im KFZ-Bereich benötigt werden) wieder diese Grenze erreiche.

auto_increment selbst nachzubauen macht in meinen Augen keinen Sinn.

Doch... tut es. Aus oben genannten Grund. Und leider konnte ich im Web bzw. Doku nichts darüber finden, ob bzw. wie ich ein Autoincrement über 2 Tabellen einrichten kann. Das wäre dann natürlich das ideale.

Abgesehen davon:
2 Artikelgruppen = 2 Tabellen.
Alleine schon der Übersichtlichkeit viel besser. Wer weiß, was die Zukunft bringt. Vllt. kommt ja noch eine andere Artikel-gruppe hinzu. Irgendwann wird die Grenze 100%tig erreicht sein... und alles auf TEXT statts varchar umzustellen, ist auch blöd

[nikosch]

Sicherlich deshalb, weil ich mittels varchar(255) recht bedenkenlos damit umgegangen bin... aber selbst nach der Aktualisierung dürfte da nicht mehr viel frei sein, so das ich wohl mit weiteren Eiongabefeldern (die halt nur im KFZ-Bereich benötigt werden) wieder diese Grenze erreiche.

Und wieder einer, der Normalisierung nicht verstanden hat. Wobei ich wetten würde, dass Dir das hier bestimmt schon mal wer erzählt hat.

Aus oben genannten Grund. Und leider konnte ich im Web bzw. Doku nichts darüber finden, ob bzw. wie ich ein Autoincrement über 2 Tabellen einrichten kann.

Ja, weil es nicht geht.

[noop]

Und wieder einer, der Normalisierung nicht verstanden hat. Wobei ich wetten würde, dass Dir das hier bestimmt schon mal wer erzählt hat.

Nicht das ich wüste... wobei mir "Normalisierung" schon nichts sagt.

Es gibt schon Felder, die ich mit varchar(xxx) belegen muß.
Z.B. der Titel. Text würde da wohl übertrieben sein... obwohl ich damit das Limit umgehen kann.
Andere Felder sind dann schon mit date / int etc.

Mittlerweile hab ich es ja auch verbessert.... was aber nichts am Grundproblem ändert.

Hier vvlt. mal die Tabellen-Struktur (nur die verwendeten Felder)

int(10)  
int(10) 
tinyint(3) 
int(11) 
varchar(50) 
enum('ja') 
enum('ja') 
enum('ja','nein') 
varchar(255) 
varchar(255) 
text 
text 
text 
text 
text 
float 
enum('brutto','netto') 
enum('stueck','gewicht') 
int(10) 
varchar(10) 
varchar(10) 
varchar(10) 
enum('ja','nein') 
enum('ja','nein') 
varchar(10) 
varchar(10) 
varchar(50) 
varchar(10) 
varchar(10) 
varchar(10) 
int(10) 
enum('ja') 
varchar(255) 
int(10) 
float 
float 
int(23) 
varchar(255) 
varchar(19) 
varchar(255) 
int(23) 
varchar(255) 
varchar(19) 
varchar(255) 
varchar(20) 
int(2) 
varchar(100) 
varchar(100) 
varchar(100) 
varchar(100) 
varchar(100) 
int(10) 



Zeilenstatistik    Angaben  	Wert
Format 	dynamisch
Kollation 	utf8_general_ci
Zeilen 	2,604
Zeilenlänge ø 	340
Zeilengröße ø 	351 Bytes
Nächste Autoindex 	430,531
Erzeugt am 	24. Februar 2010 um 22:46
Aktualisiert am 	01. August 2010 um 13:25
Letzter Check am 	31. Juli 2010 um 17:57


Speicherplatzverbrauch    Typ  	Verbrauch
Daten 	865,8 	KiB
Index 	28,672 	Bytes
Insgesamt 	893,8 	KiB

Und das ist nur eine Tabelle.
Ich hab es jetzt nach dem optimierten Zustand zwar noch nicht versucht beide Artikelgruppen zusammenzuführen... aber selbst wenn es ginge, wäre ich irgendwann mal am Limit.


Drum würde ich bitten, wieder zurück zum Topic zu kommen.

[nikosch]

Drum würde ich bitten, wieder zurück zum Topic zu kommen.

Das ist genau das Thema. Deine gesamte Datenbankstruktur ist Müll. Und wenn Du schlau warst, hast Du wenigstens jetzt schon Normalisierung nachgeschlagen.

[Flor1an]

Du willst in 2 Tabellen nicht die selben ID vergeben? Das klingt sehr nach falschen Datenbankdesign! Speicher alle Artikel in EINER Tabelle und füge eine Spalte hinzu in der steht zu welcher Kategorie der Artikel gehört (Lebensmittel/KFZ/etc). Dann brauchst du die auto_increment ID auch nicht selbst zu bestimmten sondern kannst einfach immer einen Artikel hinzufügen, den Rest macht die DB.

Beitrag editiert:
Verdammt viel zu spät, man sollte nich nen Thread öffnen und ne Stunde später antworten

[noop]

Habe ich...und zwar vorhin schon. Jetzt aber nochmal genauer.

Ich denke mal, das du mit "Normalisierung" das meinst, gewisse Spalten über mehrere Tabellen "erstrecken zu lassen".

Sprich: 1 Tabelle mit den Hauptdaten. 2 Tabelle mit den Preisstaffeln.
3te Tabelle mit den Artikel-Varianten etc.

Wenn dem so ist <= dann habe ich dies bereits schon. (Kategorie,Bilder,Preise,Varianten und die Haupttabelle)

[Flor1an]

Nein, was Normalisierung bedeutet liest du bitte in Wikipedia oder sonst wo nach.

Es bedeutet das du für Artikel nicht zwei Tabellen hast sondern eine!

[noop]

Du willst in 2 Tabellen nicht die selben ID vergeben? Das klingt sehr nach falschen Datenbankdesign! Speicher alle Artikel in EINER Tabelle und füge eine Spalte hinzu in der steht zu welcher Kategorie der Artikel gehört (Lebensmittel/KFZ/etc). Dann brauchst du die auto_increment ID auch nicht selbst zu bestimmten sondern kannst einfach immer einen Artikel hinzufügen, den Rest macht die DB.

Was ja Patrick Hilker schon vorgeschlagen hat.

Eigendlich wollte ich es schlank halten. Je mehr Tabellen bestehen, umso mehr INNER JOIN's / UNION etc durchführen, um ein kompletten Datensatz zu erhalten.

Aber nach genauerer Überlegungen gebe ich euch recht. Ich verknüpfe eh schon bis zu 5 Tabellen... da macht dann eine Tabelle mehr oder weniger auch nichts mehr.

Oki... ich setze es dann mit einer neuen Tabelle um, die dann erstmal dafür zuständig ist, welcher Artikel zur welchen Tabelle gehört

[noop]

Nein, was Normalisierung bedeutet liest du bitte in Wikipedia oder sonst wo nach.

Es bedeutet das du für Artikel nicht zwei Tabellen hast sondern eine!

Normalisierung (Datenbank) – Wikipedia <= ich bin dran..

Da hier grad 2 Moderatoren im Thread sind... und ich es auch grad ebend entdeckt habe:

Wen hab ich das denn zu "verdanken" ?

noop zeigte ein beschämendes Verhalten in der Vergangenheit

In mein Profil sehe ich zwar 2 Punkte (Verwarnungspunkte ???)
allerdings mit folgenden Hinweisen:

1: lern bitte endlich, probleme *vernünftig* zu beschreiben!
2: immer noch niveaulos

Wo ist das denn bitte schön ein "beschämendes Verhalten" ?
Ich poste meine Probleme so, wie mir diese vorliegen und nach besten Wissen. Ob das mein Gegenüber versteht ist dann ne andere Sache. Da kann man ja nochmal Nachfragen.
Aber gleich solch ein "Titel" dafür zu bekommen... ärgerlich!!!


Wie werd ich denn diesen Roten Punkt wieder los ?
Oder isses hier wie in Felsburg = nach 2 Jahren ohne weitere Vorfälle, verfallen diese (?)