Paging von Daten

[bussibaer]

Mit pconnect und autocommit, das andere ist leider zu langsam.

[RobertPic]

So jetzt muss ich auch noch meinem Senf dazugeben:

1. Hier der Syntax für Paging auf der AS/400:

SELECT * FROM                                 
 ( SELECT kunde.*, rownumber() over( ORDER BY  
    firnr, kunr ) as rownum               
 FROM mkun WHERE firnr = 1 and         name like '%MAIER%' )                
 as inner where rownum between 50 and 100

Ich habe zwar noch keine Probleme ohne gehabt, aber es wird empfohlen in der ORDER BY einen eindeutigen Schlüssel zu haben - also zumindest an die Wunschsortierung dranhängen.

Bei großen Dateien habe ich bessere Erfahrungen gemacht, wenn auch der inner Join gleich sortiert ist:

SELECT * FROM                                          
 ( SELECT kunde.*, rownumber() over( ORDER BY           
    firnr, kunr ) as rownum                        
 FROM kunde WHERE firnr = 1 and                        
    name like '%MAIER%' order by firnr, kunr) 
 as inner where rownum between 50 and 100

Bei diesem Select werden die Zeilen 50-100 ausgegeben.

2. PHP: iieeehhh...

3a) Denn SQL-Syntax habe den Hibernatesourcen entnommen. Wenn man mit Hibernate arbeitet braucht man davon nichts zu wissen..

3b. Bei größeren Anwendungen zahlt sich Hibernate (Java) bzw. NHibernate (für Dot.Net) aus. Für die optimale Performance muss man sich dann aber schon richtig damit beschäftigen.

Bei meinem letzten Project habe auch noch das Feature Hibernate Search verwendet:

Neben der Datenbankanbindung kann man mit wenigen (fett) Schlüsselwörtern auch die Indexierung für die Volltextsuche mitmachen lassen - im Hintergrund werkelt Lucene. Auf diese Weise ist es ein leichtes den Anwender schnell mal
nach: Name/Ort/Postleitzahl suchen zu lassen, z.B. MAIER WIEN.

Einfacher ist das Leben sicher mit Id's statt Multikeyfeldern, Hibernate bietet aber immer eine Möglichkeit an, Multikeyfelder abzubilden.

Noch noch was zu Java: So manchem Umsteiger mögen die "vielen" Schichten in Java speziell bei der Trennung von Model, Controll und View als Overhead hoch 5 vorkommen.

Aber gerade durch die eigene Modelschicht die z.B. eine Funktion für die Kundensuche hat, ist es leicht eine langsame (oder schlechte wg. z.B. Umlaut ae <> ä) Datenbanksuche durch eine Volltextsuche zu ersetzen.


Hier noch eine Beispielklasse (~ Record der Datei KUNDE)
@Entity
@Table(name = "KUNDE")
@Indexed
@Analyzer(impl = GermanUmlautAnalyzer.class)

public class Kunde implements Serializable {


@Id
@DocumentId(name="firkund")
@FieldBridge(impl = com.at.od.notlauf.model.domains.KundenPKBridge.cla ss)
@EmbeddedId
KundePK kundePK; // Darstellung Mehrfachschlüssel
@ManyToOne
@JoinColumn(name="FIRMA", referencedColumnName = "FIRMA",insertable=false,updatable=false)
Firma firma;

@Column(name = "NAME")
@Field(index=Index.TOKENIZED, store=Store.NO)
@Boost(2f)
String name;

@Column(name = "ZUSATZ")
String zusatz;
@Column(name = "STRASSE")
String strasse;
@Column(name = "ORT")
@Field(index=Index.TOKENIZED, store=Store.NO)
String ort;

@Column(name = "PLZ")
@Field(index=Index.UN_TOKENIZED, store=Store.NO)
String plz;

@Column(name = "LAND")
String land;
@Column(name = "KURZBEZ")
@Field(index=Index.TOKENIZED, store=Store.NO)
String kurzBezeichnung;
@Column(name = "BONICD")
int boniCode;