Felder aus meheren Datensätzen verketten - langsam

[JannesDKS]

Moin Leute,

ich habe 2 Tabellen: Adressen und eine Tabelle wo Eigenschaften zu den Adressen angelegt werden können.

Nun gab es die Anforderung in einem View in einem Feld die Eigenschaften als verketteten String anzuzeigen.
Also das Ergebnis sieht ungefähr so aus:
'Makler;Newsletter;Weihnachtskarte'.

ich hab das auch schon hinbekommen indem ich eine Stored-Procedure geschrieben habe, die die Datensätze durchläuft und verkettet. Ist aber bei vielen Datensätzendoch recht langsam.
Hier meine Lösung:

SQL-Code:

create or alter procedure CREATE_SELECTION_CHAIN (
    ADDRESSNO varchar(10))
returns (
    SELECTION varchar(500))
as
declare variable SEL varchar(500);
declare variable SELECTIONBUFFER varchar(500);
begin
  sel = '';
  for select property_NAME from property_value_combination pvc
  where pvc.address_no = :addressno
  and pvc.contact_no is null
  into :selectionbuffer
  do begin
    sel = sel ||  ';' || selectionbuffer;
  end
  selection = sel;
  suspend;
end^

Hat da vielleicht jemand von euch ne Idee, wie man das beschleunigen könnte?

[p80286]

warum machst Du es nicht so:

SQL-Code:

select Adresse,Eigenschaft1||Eigenschft2||....||Eigenschaftn from AdressTable,EigenschaftTable...

Gruß
K-H

[DeddyH]

Weil er wohl die Datensätze miteinander verketten muss und nicht die Spalten.

[tsteinmaurer]

Die Schleife an sich sollte nicht das Problem sein, d.h. ich würd mal schaun, was das SELECT:

Code:

select
  property_NAME
from
  property_value_combination pvc
where
  pvc.address_no = :addressno
  and pvc.contact_no is null

Alleine für eine Ausführungszeit hat.

- Wie sieht der Zugriffsplan (PLAN) aus?
- Gibt es Indizes auf der Tabelle?

Bzgl. Verkettung gibt es seit Firebird 2.1 auch die LIST Funktion, die dir einen Wert eines Feldes aus mehreren Datensätzen miteinander verketten kann. D.h., nur fürs Verketten brauchst keine Stored Procedure.

[JannesDKS]

Moin Thomas,

List werd ich mir mal ansehen, klingt so als wär es das, was ich suche. Es geht mir echt nur um die Performanz. Hab mir den Plan schon angesehen, es gibt keine non-indexed reads. Es sind einfach zu viele Datensätze. Mal schauen, ob list schneller ist.
Danke für den Tipp.

[JannesDKS]

Hm Geschwindigkeit ist nahezu gleich, ich werd trotzdem List verwenden. Ist auf jeden Fall die elegantere Lösung.
Falls noch jemand eine idee hat, wie man diese Aufgabe beschleunigen kann, wär ich sehr dankbar. Bei uns werden öfter Reports auf eine große Anzahl von Adressen gemacht (so um die 10.000) und mit der Verkettung dauert die Abfrage ca 1 Minute, ohne nur 340 ms. Am liebsten würd ich das einfach rausschmeißen, aber die Anwender wollen das haben ;-)

[tsteinmaurer]

- Zeig mal das finale Statement
- Den Ausführungsplan
- Welche Indizes existieren für die abgefragten Tabellen
- Wieviele Datensätze sind in den abgefragten Tabellen

[FredlFesl]

Du kannst mit einer redundanten Hilfstabelle arbeiten, die die konkatenierten Strings enthält. Über Trigger der Tabelle property_value_combination steuerst du den Inhalt. Im Einzelnen wird bei jeder Änderung der Tabelle der korrespondierende Eintrag der Hilfstabelle mit deiner Funktion neu erstellt. Dann hast Du die fertigen Strings ständig auf Lager und der Report geht dann ratzfatz.

Ich würde dem Kunden aber nur erklären, das dieser Wunsch eher ungewöhnlich ist und der Datenbankstruktur wiederspricht und das keine DB-Struktur alle Anfragen in optimaler Zeit beantworten kann.

Falls Du einen Reportgenerator hast, den man erweitern kann (Skript-Enginge), könntest Du auch das Konkatenieren im Report selbst vornehmen.


Unter uns: 1 Sekunde für 10.000 Datensätze ist doch flott genug, oder nicht?

[DeddyH]

Zitat:

Zitat von FredlFesl (Beitrag 1116145)

Unter uns: 1 Sekunde für 10.000 Datensätze ist doch flott genug, oder nicht?

Es sind aber 60 Sekunden ;)

[jaevencooler]

Moin, Moin,
ich war mal so frei das auf einer Oracle nach zu bauen, sieht dann so aus :

Delphi-Quellcode:

CREATE OR REPLACE FUNCTION CREATE_SELECTION_CHAIN ( ADDRESSNO in varchar2)

RETURN varchar2 AS
 SEL varchar2(500); -- oder größer ??

 cursor cTestCursor is
   select property_NAME from
   property_value_combination
   where address_no = addressno
     and contact_no is null;

  tTestCursor cTestCursor%RowType;


BEGIN
  sel := '';

  for tTestCursor in cTestCursor
  loop
    sel := sel || ';' || tTestCursor.property_NAME;

  end loop;

  return sel;

  exception
    when others then
      return 'Fehler';
END;

ich weiß, ist kein delphi Quellcode, ist PL/SQL..... 8-)

braucht für 10.000 zufällig generierte Datensätze ca. 1,5 Sekunden, abhängig von der Länge
der String die concatiert werden. (Dazu muss dann auch die Variable "sel" vergrößert werden)

Ich gehe mal davon aus das dein SQL schlecht funktioniert, vielleicht zieht der Index nicht ?
(eventuell machst du jedes Mal einen Full Table Scan)

Ich würde wirklich mal einen SQL Plan erstellen, da kannst Du sehen was langsam läuft.

Beste Grüße
Michael

[mkinzler]

Man könnte es auch mit der LIST()-Aggregatfunktion versuchen

[DeddyH]

Das wurde zwar bereits in #4 erwähnt, aber gut, dass Du es noch einmal gesagt hast. Hat das eigentlich schon jemand ausprobiert und kann etwas zur Performance sagen? Ich könnte mir vorstellen, dass es damit schneller geht als mit einer SP.

[himitsu]

Sagte er nicht, daß er LIST schon ausprobiert hatte?

Ergebnis: ist etwa gleich schnell/langsam (glaub ich)

[DeddyH]

Ahja, #6.

[tsteinmaurer]

Im Prinzip steht bereits in #4 alles drin, was wir brauchen. :-D

[DeddyH]

Das will auch niemand bestreiten ;)

[JannesDKS]

Hi Leute,

find ich total toll, dass ihr euch so viel Gedanken macht.

EDIT!

hab das Problem identifziert: in der Tabelle Property_Value_Combination werden auch Eigenschaften für andere Tabellen gespeichert. Hab jetzt das Statement (hier gekürzt, sind natürlich viel mehr Felder) wie folgt angepasst:

select list (distinct Property_name) as SELECTION,adress_no
from adress
left join property_value_combination on (adress.adress_no=property_value_combination.addre ss_no
and contact_no is null
and calc_header_id is null
and file_id is null
and vesselentry_id is null)

group by adress_no
so dauert es nur so 6-7 Sekunden. Da hab ich gar nicht drüber nachgedacht.

[tsteinmaurer]

Sollte der LEFT JOIN durch einen INNER JOIN ersetzbar sein, dann könntest bzgl. Performance ev. noch mehr rausholen.

Wennst willst und die Datenbank gezippt nicht zu gross ist, dann könntest du mir die Datenbank schicken (ts @ iblogmanager . com) und ich schau, ob sich noch was machen lässt. Wenn du sie schickst, dann bräuchte noch die genaue Firebird Version und etwaige UDF-Bibliotheken, die von der Datenbank verwendet werden.

[JannesDKS]

Hi Thomas,

ein Inner Join geht leider nicht, da es auch Adressen gibt, für die es keine Einträge in der Properties-Tabelle gibt.
Ich denke so ist die Performance völlig in Ordnung. Aber danke für das Angebot. Die DB darf ich auch nicht an Dritte weitergeben.

[FredlFesl]

Zitat:

Zitat von DeddyH (Beitrag 1116146)

Zitat:

Zitat von FredlFesl (Beitrag 1116145)

Unter uns: 1 Sekunde für 10.000 Datensätze ist doch flott genug, oder nicht?

Es sind aber 60 Sekunden ;)

Ich schwöre, ich hab "Minute" geschrieben! Ehrlich!