Funktion für Suche in 3 Tabellen mit mehrdimensionalen Array

[djjlx]

Hallo zusammen!
Ich sitze wieder mal vor einen Problem das mich schon ein paar Tage ärgert.

Folgende Ausgangsituation:
Ich möchte verschiedene Lieferscheinnummern in der DB suchen, ich weiß die einmalige Scheinnummer und den Leistungszeitraum. Auf Grund der Eingetragenen Menge musste ich die DB in mehreren Tabellen aufteilen.
Folgenden Code hab ich bereits:

$q = Schein Nummer
$lzr = Leistungszeitraum im Format mm.yyyy

Ich hätte gerne das dass Array so aussehen sollte

Array([btbnr] => 123456, [erg] => 1, [daten] => Array([0] => start|ende|pause usw. [1] => start|ende|pause usw.));
Soweit hab ich das auch nur wenn nichts gefunden wird sollte das auch im Array stehen
mit [erg] => 0 (Dieser Code fehlt zurzeit).

Problem ist nur wenn in der ersten Tab nichts gefunden wird steht [0] in der zweiten Tab wird was gefunden steht alles korrekt im Array in der dritten Tab wird wieder nichts gefunden steht wieder [0] im Array.

In der weiteren Verarbeitung wird das Array durchlaufen und die Stunden zwischen Start und Ende berechnet und danach in einer html Tabelle ausgegeben.
Pro Berichtnummer aber nur 1 Zeile. Sprich alle gefundenen Einträge werden vor der Ausgabe addiert.

Hat jemand einen Idee wie ich das umsetzten könnte? Bzw. bin ich mit meiner Funktion am Holzweg?

Gruss
DjJLX

function search_plan($was,$q,$lzr)
{
    global $dbprefix;
    $cell = 'btb_nr';
    $select = '`btb_start`, `btb_ende`, `btb_pause`, `btb_funk`, `btb_typh`, `btb_warn`, `btb_nr`,`bfunk`, `gsmr`, `beruf`, `fid`, `mini`';
    if($lzr !== 0)
    {
        $lzr_fine = explode('.',$lzr);
        $lzr_search = mktime(0,0,0,$lzr_fine[0],1,$lzr_fine[1]);

        $result = array();
		$result['btbnr'] = $q;
		
		for($a=1; $a<=3; $a++)
		{
			if($a == 1) $lzr = $lzr_search-604800;
			if($a == 2) $lzr = $lzr_search;
			if($a == 3) $lzr = $lzr_search+3024000;
        
        	$lzr_a = date('Y_n',$lzr);

			$int = mysql_query("SHOW TABLES LIKE '".$dbprefix."_planung_%%_".$lzr_a."'");
        	while($db = mysql_fetch_row($int))
        	{		
				$int_plan = db_query("SELECT ".$select." FROM `".$db[0]."` WHERE `".$cell."` = '".$q."'");
				if(num_rows($int_plan) !== 0) 
				{
					$result['erg'] = 1;					
					$y=0;			
					while($row = mysql_fetch_array($int_plan))
					{
						$result['daten'][$y] = $row['btb_start']."|".$row['btb_ende']."|".$row['btb_pause']."|".$row['btb_funk']."|".$row['btb_typh']."|".$row['btb_warn']."|".$row['btb_nr']."|".$row['bfunk']."|".$row['gsmr']."|".$row['beruf']."|".$row['fid']."|".$row['mini'];
                		$y++;
					}
					
				}
				else
				{
					//Nichts gefunden
				}
	
			}
        }    
     
    }
    return $result;
}

 

[Sebbo]

Auf Grund der Eingetragenen Menge musste ich die DB in mehreren Tabellen aufteilen.

Wie viele Zeilen gibts denn? Das ist meistens nicht nötig. Wenn es ne vernünftige Struktur gibt (und Indizes), dann kommt ne DB mit sehr sehr viele Zeilen klar.


Wenn ich dich richtig verstanden habe (und die die Daten über 3 Tabellen splittest), dann gibts in der zweiten Tabelle einen Treffer, aber weil er danach noch die dritte prüft, wird der Treffer aus der zweiten überschrieben. Und es kann mehrere Treffer pro Anfrage geben? (Also es könnte auch in Tabelle 1, 2 und 3 einen oder mehrere Treffer geben?)

In dem Fall brauchst du für jede Tabelle ein eigenes Ergebnis-Array. Die musst du dann am Ende noch Auswerten und zusammenführen:
- alle 3 haben kein Ergebnis -> [erg] => 0
- ansonsten die ergebnisse zusammenführen, die es gibt (natürlich nicht, wenn [erg] == 0)

 

[Mexxim]

Wie viele Zeilen gibts denn? Das ist meistens nicht nötig. Wenn es ne vernünftige Struktur gibt (und Indizes), dann kommt ne DB mit sehr sehr viele Zeilen klar.

Korrekt, "Hardware is cheaper than development"
Selbst ein popeliger Webspace kommt mit ein paar 10.000 Einträgen zurecht, ein kleiner v-Server reicht auch noch für Millionen von einträgen, solang diese ordentlich indiziert und nicht von 5000 Usern gleichzeitig abgefragt werden

also überdenke diese Entscheidung nochmal, das erspart dir sicherlich einiges an Zeit.

Mfg

 

[ice-breaker]

Mexxim, deine Aussage unterstützt aber nicht Sebbos Aussage sondern widerspricht ihr
Mit deiner Aussage unterstützt du die "Lösung" (?) von djjlx: hässlich, derbst unperformant aber funktioniert irgendwie vllt schon, die Hardware wird das Performanceproblem schon ausgleichen.

Sebbo hingegegen sagt, dass hier korrekterweise die Datenbankstruktur angepasst werden sollte, um dieses Problem zu lösen. Also Entwicklungsarbeit hinenzustecken und das Problem nicht durch mehr Hardware zu lösen.

 

[Mexxim]

So wie ich das verstanden habe war die datenbank schoneinmal "in einem Stück", er hat sie jetzt nur auseinander genommen weil er meinte das es so schneller ist. Sprich er müsste einfach nur die weiteren schritte verwerfen und eine einfache, ordentliche und performante Abfrage für die ursprüngliche Tabelle schreiben- womit er sich die aufwändige entwicklungszeit für die schwierige Abfragestruktur spart?