hindre like lik data i kolonne [Løst]

[Manfred]

Hvorfor har du en ENUM('aktiv', 'ikke aktiv') som status i tabellen? Kunne du ikke enklere hatt aktiv boolean?

 

Mulig det bare er en smakssak fra min side, men jeg mener det er ekstremt sjelden man bør bruke ENUMs.

[blackbrrd]

Irriterende med boolean felter også, er endel ganger jeg har hatt lyst å ha en tredje eller fjerde verdi istedetfor de to (tre med NULL) verdiene boolean felt gir.

[Manfred]

Da har jeg som oftest foreign keys til en annen tabell. Ellers blir det så jævlig rigid uten muligheter for endringer.

[blackbrrd]

Da har jeg som oftest foreign keys til en annen tabell. Ellers blir det så jævlig rigid uten muligheter for endringer.

.... ja, det var derfor jeg nevnte at boolean felter heller ikke behøver å være noen god ide.

 

Løsningen er selvfølgelig den samme som du kom med.

[t0bbi]

Hvorfor har du en ENUM('aktiv', 'ikke aktiv') som status i tabellen? Kunne du ikke enklere hatt aktiv boolean?

 

Mulig det bare er en smakssak fra min side, men jeg mener det er ekstremt sjelden man bør bruke ENUMs.

 

Muligens det er enklere med boolean, men spørsmålet mitt gikk jo ut på om hva jeg gjør galt siden jeg ikke får boolean til å virke. Hvis noen forteller meg det kan jeg sikkert bruke boolean i stedenfor enum :-)

[roac]

Hibernate lager jo sql direkte ut fra hva du skriver, men du slipper å lage metodene for å gjøre om result-settet til java-objekter.

 

F.eks HQL-en

 

SELECT a FROM torder a

INNER JOIN FETCH a.torderstatus b

 

Blir gjort om til f.eks:

SELECT a.*, b.* FROM torder a

INNER JOIN a.torderstatus b ON a.orderid = b.id_orderid

 

Ser ikke helt hva som er problemet her, utenom med sql-en da, som man manuelt må gjøre om til java objekter (tidkrevende å kode).

Hibernate er laget for å tilnærmet abstrahere bort databaselaget, som ytelsesmessig kanskje er det viktigste laget i flerlagsarkitektur, og hindrer (ut fra det jeg har sett) eller stimulerer garantert ikke til bruk av spørringer som er spesialisert for en databasemotor for optimal ytelse. Bruk av funksjonalitet som CTE og windowing funcitons i f eks SQL Server 2005 kan man etter det jeg har erfart bare glemme dersom Hibernate blir brukt. Noen må gjerne rette meg dersom jeg tar feil, men etter det jeg har sett av Hibernate så egner det seg kun for de som driter fullstendig i ytelsen fra databaseserveren og for enhver pris (deriblant ytelse) vil ha så enkel kode som mulig.

 

Irriterende med boolean felter også, er endel ganger jeg har hatt lyst å ha en tredje eller fjerde verdi istedetfor de to (tre med NULL) verdiene boolean felt gir.

Dette er da ikke noe problem? I de tilfellene er jeg sikker på at det blir avklart i designfasen slik at du ikke bruker boolean i de tilfellene.

 

Da har jeg som oftest foreign keys til en annen tabell. Ellers blir det så jævlig rigid uten muligheter for endringer.

Glad du sa som oftest. Jeg får "noia" når jeg ser en egen tabell for kjønn med tre rader, for henholdsvis mann, kvinne og ukjent

[blackbrrd]

roac: leste du kommentaren min, to poster over din? :o)

.... ja, det var derfor jeg nevnte at boolean felter heller ikke behøver å være noen god ide.

 

Angående Hibernate så finnes det selvfølgelig flere steder hvor det ikke passer å bruke det, men jeg ser ikke helt problemet. Du kan kombinerere HQL og SQL som det passer deg.

 

F.eks hvis du skal lage noen admin-vinduer som brukes en gang hver 14. dag til å gjøre noen få update/insert/delete setninger er det ikke noe poeng å bruke 5x så lang tid på å skrive disse manuellt med SQL istedetfor å bruke den objektorienterte tankengangen du kan benytte hvis du bruker Hibernate. (Som erfaringsmessig for meg som faktisk bruker mye sql og hql gir kanskje 1/5 så mye kode)

 

Hva er forresten problemet med en tabell for kjønn med tre rader? Du mener vel kanskje at du skal bruke ett boolean felt som tillater null verdier? :o)

[roac]

roac: leste du kommentaren min, to poster over din? :o)

.... ja, det var derfor jeg nevnte at boolean felter heller ikke behøver å være noen god ide.

 

Angående Hibernate så finnes det selvfølgelig flere steder hvor det ikke passer å bruke det, men jeg ser ikke helt problemet. Du kan kombinerere HQL og SQL som det passer deg.

 

F.eks hvis du skal lage noen admin-vinduer som brukes en gang hver 14. dag til å gjøre noen få update/insert/delete setninger er det ikke noe poeng å bruke 5x så lang tid på å skrive disse manuellt med SQL istedetfor å bruke den objektorienterte tankengangen du kan benytte hvis du bruker Hibernate. (Som erfaringsmessig for meg som faktisk bruker mye sql og hql gir kanskje 1/5 så mye kode)

 

Hva er forresten problemet med en tabell for kjønn med tre rader? Du mener vel kanskje at du skal bruke ett boolean felt som tillater null verdier? :o)

Mulig det gikk litt fort og at jeg ikke fikk med meg alt.

 

Selvfølgelig, i en teoretisk verden fungerer det fint og du kan bruke forskjellige verktøy og metoder avhengig av hva som skal gjøres. Men, jeg har jobbet med utvikling i flere bedrifter, og jobbet med utviklere i enda flere, og all erfaring tilsier at den enkle metoden er den som foretrekkes, selv om det tidvis er LANGT fra den beste løsningen. Det finnes selvfølgelig unntak som bekrefter regelen

 

Nei, jeg mener overhodet ikke at du skal bruke boolean til kjønn, det er dønn unaturlig i og med at boolean av natur er sann/usann. Det jeg mener er at man godt kan bruke en bokstav for å representere kjønn, f eks M, K, U (evt M, F, U hvis du foretrekker den engelske varianten). Presentasjonen av disse (som er et statisk sett av verdier) hører vel strengt tatt til på presentasjonslaget. Dette er forresten et tilfelle hvor jeg mener enum kan være egnet, i de databasemotorer som støtter dette.

 

Når det gjelder mer dynamiske sett av verdier, som f eks medietype i en musikkarkiv, så ser jeg helt klart nytten av å kunne legge til nye verdier, og dette vil være et tilfelle hvor jeg vil finne det naturlig å trekke atributtet ut i en egen tabell for å lette dette.

[blackbrrd]

Det er kanskje litt omstendelig å bruke en egen tabell for kjønn, men for alle som kan bruke relasjonsdatabaser så vil det være helt klart hvilket kjønn det er snakk om.

 

Å bruke forkortelser som M, K og U er noe av det første du lærer som programmerer at du skal holde deg unna. Der og da virker det helt naturlig å bruke forkortelsene, men på ett eller annet tidspunkt så ser du på noe gammel kode med forkortelser og tenker: "Hæ?!? Hva har jeg tenkt her?"

 

Personlig hadde jeg brukt en tabell med kjønn og referanser til den. Noe omstendelig, men det skal mye til å misforstå hva du mener. I programmet som bruker databasen så hadde jeg antageligvis definert to variabler, FEMALE = 1, MALE = 2, eller lignende. På den måten trenger jeg hverken når jeg programmerer eller leser database gjette meg til hva disse verdiene er for noe.

 

Helt enig angående programmerere, de er late, akkurat som alle andre mennesker, så de får for det enkle og trege. Men det er ikke Hibernate sin skyld! Det er et verktøy som alt annet.

 

Personlig foretrekker jeg å lage en prototype som er så enkel som mulig først, for så å se hva som må forbedres. Det er vanligvis ganske lett å identifisere kode som går tregt og fikse på den.

 

F.eks er det kjapt å gå på blemmer i Hibernate som å laste collections inn i minne før du sletter dem. Dette fører til en og en SQL DELETE statement istedetfor å kjøre en SQL DELETE statement for hele greia som du hadde gjort hvis du brukte SQL direkte.

 

Jeg jobber stort sett med et program som kjører en tre-lags arkitektur. Mao, databaseserver, applikasjonsserver og klient. Det er definitivt databaseserveren som får gjennomgå mest. Vi bruker linux og da ligger gjerne loaden på databaseserveren på 1-2, mens loaden på applikasjonsserveren gjerne ligger på 0,01 - 0,1. For meg som utvikler vil det si at jeg stort sett konsentrer meg om å optimalisere bruken av databasen. Om applikasjonsserveren må gjøre litt ekstra arbeid bryr det meg fint lite (innenfor visse rammer).

 

En av tankegangene til Hibernate er at å hente ut en hel rad, eller deler av raden ikke spiller så stor rolle, noe som stemmer 95% av tiden. Mao blir det ofte hentet ut noen unødvendige objekter, men ikke noen unødvendige rader. Dette fører til økt load på applikasjonsserveren, men for f.eks den applikasjonen jeg jobber med så har det lite å si.

 

Den siste flaskehalsen vi har er latency mellom applikasjonsserver og klient, ettersom dette mye av tiden går over relativt trege VPN linjer. 10 små kall tar mye lengre tid enn 1 stort hvis de 10 kallene blir gjort sekvensiellt.

Endret 11. februar 2008 av blackbrrd