Lage tabeller for hver event eller en felles tabell ?

[pedero]

Hei, driver å planlegger en billett app.

 

Jeg har kommet et godt stykke på veien med planleggingen, men jeg har kommet til et punkt der jeg må klø meg litt i hue.

 

Jeg tenker å lagre alt av data på hvert arrangemang/event i en database, men jeg lurte på om det er best å bruke en felles tabell for alle bilettene, en for alt av en anne datatype osv., eller om jeg burde lag egen egen tabell for hvert arrangement der alle billettene er lagret ?

 

Takk på forhånd

[Emancipate]

Jeg vil tro det er best med en tabell for billetter, uavhengig av arrangement.

 

CREATE TABLE tickets (id INTEGER PRIMARY KEY, holders_name TEXT, arrangement INTEGER);

 

Edit: Men et problem er hvordan du skal håndtere det at forskjellige arrangementer har forskjellige restriksjoner på seteplasser.

Endret 29. januar 2015 av Emancipate

[pedero]

Har lest litt på denne artikelen(http://www.codeproject.com/Articles/359654/important-database-designing-rules-which-I-fo) og noen andre nå.

 

Ville det vært best å hatt en tabell med alle arrangementene, så bruke en forign key for å koble den opp mot en brukerdatabase med hvem som er arrangør, en database med en forign key til event databasen, osv. ?

[pedero]

Jeg vil tro det er best med en tabell for billetter, uavhengig av arrangement.

 

CREATE TABLE tickets (id INTEGER PRIMARY KEY, holders_name TEXT, arrangement INTEGER);

 

Edit: Men et problem er hvordan du skal håndtere det at forskjellige arrangementer har forskjellige restriksjoner på seteplasser.

Har tenkt litt på det der med seteplasser selv, vet ikke hel hva målgruppen min skal være enda. Hvis jeg velger for å gå for relativt små arrangement 200-400 plasser er det vel ikke noe øyeblikkelig behov for å kunne bestille en viss plass(større aktører ville vel ha brukt mere establiserte aktører som billetservise), så for verson 1.0 av appen tror jeg jeg skal gå for en maks antall seteplasser løsning som lagres sammen med arrangementet i databasen.

[Emancipate]

Det smarteste er nok om du skriver ned 110% presis hva slags funksjonalitet appen skal ha mtp hvilke data som skal lagres (seter, priser, etc). Og så designer du databasen etterpå.

[Enthroner]

Du burde velge deg en ORM http://en.wikipedia.org/wiki/Object-relational_mappingfor språket ditt.

Så skriver du koden slik du vil den skal være også kan du la ORM bekymre seg for hvordan å lagre i tabeller. Du kan alltids bestemme dettemselv i tillegg dersom du føler du må det.

 

Hvilket språk skal du skrive i?

[pedero]

Du burde velge deg en ORM http://en.wikipedia.org/wiki/Object-relational_mappingfor språket ditt.

Så skriver du koden slik du vil den skal være også kan du la ORM bekymre seg for hvordan å lagre i tabeller. Du kan alltids bestemme dettemselv i tillegg dersom du føler du må det.

 

Hvilket språk skal du skrive i?

Bruker play framework for rest apien så det blir Java

 

EDIT: er ganske ny til play framework men tror det har en innebygg orm i form av ebean. Har lekt litt med det, og det er virkelig lekende lett å kommunisere med databasen igjennom ebean.

Endret 30. januar 2015 av pedero

[quantum]

Du burde velge deg en ORM http://en.wikipedia.org/wiki/Object-relational_mappingfor språket ditt.

Så skriver du koden slik du vil den skal være også kan du la ORM bekymre seg for hvordan å lagre i tabeller. Du kan alltids bestemme dettemselv i tillegg dersom du føler du må det.

 

 

Klart man kan velge å stille de samme spørsmålene på domenemodellnivå isteden ... men svarene gir seg uansett ikke av seg selv.

[quantum]

eller om jeg burde lag egen egen tabell for hvert arrangement der alle billettene er lagret ?

 

Takk på forhånd

 

Du skal ikke lage en ny tabell for hvert nye arrangement.

[quantum]

Har lest litt på denne artikelen(http://www.codeproject.com/Articles/359654/important-database-designing-rules-which-I-fo) og noen andre nå.

 

Ville det vært best å hatt en tabell med alle arrangementene, så bruke en forign key for å koble den opp mot en brukerdatabase med hvem som er arrangør, en database med en forign key til event databasen, osv. ?

 

Ja, det høres ut som du er på sporet nå. Du bør også lese deg opp på databasenormalisering, feks http://en.wikipedia.org/wiki/Database_normalization

[Enthroner]

 

Du burde velge deg en ORM http://en.wikipedia.org/wiki/Object-relational_mappingfor språket ditt.

Så skriver du koden slik du vil den skal være også kan du la ORM bekymre seg for hvordan å lagre i tabeller. Du kan alltids bestemme dettemselv i tillegg dersom du føler du må det.

 

 

Klart man kan velge å stille de samme spørsmålene på domenemodellnivå isteden ... men svarene gir seg uansett ikke av seg selv.

 

Svarene på spørsmålene han stiller blir besvart i og med at designet på databasen ikke lenger er utviklers ansvar.

 

I tillegg sørger en ORM for at alle databaseprinsipper blir forsterket og etterfulgt.

 

Du kan bare designe domenemodellen slik du føler det naturlig, og la mapperen finne ut hvordan modellen best mappes til en database.

[pedero]

 

 

Du burde velge deg en ORM http://en.wikipedia.org/wiki/Object-relational_mappingfor språket ditt.

Så skriver du koden slik du vil den skal være også kan du la ORM bekymre seg for hvordan å lagre i tabeller. Du kan alltids bestemme dettemselv i tillegg dersom du føler du må det.

 

 

Klart man kan velge å stille de samme spørsmålene på domenemodellnivå isteden ... men svarene gir seg uansett ikke av seg selv.

 

Svarene på spørsmålene han stiller blir besvart i og med at designet på databasen ikke lenger er utviklers ansvar.

 

I tillegg sørger en ORM for at alle databaseprinsipper blir forsterket og etterfulgt.

 

Du kan bare designe domenemodellen slik du føler det naturlig, og la mapperen finne ut hvordan modellen best mappes til en database.

 

Men det jeg er redd for hvis jeg bruker et ORM er at jeg vil ende opp med en dårlig designet database, som det vil være vanskelig å legge til nye funksjoner/felter og tabeller i.

 

Er dette et stort problem med ORM ?

[Enthroner]

Med en god ORM så skal du aldri bruke SQL for å gjøre endringer. Du koder en "migration" slik at du kan rulle endringen inn og ut av databasen. Lager du en ny klasse eller et nytt felt så genereres en migration med denne endringen.

Stored procedures er i min verden et antipattern. Businesslogikk hører ikke hjemme i databaselaget.

 

Dersom du er uenig med designet ORMen lagrer så har de helt sikkert en måte å gjøre overrides på via konfigurasjon. Dette vil selvsagt variere fra en ORM til den neste.

[pedero]

Med en god ORM så skal du aldri bruke SQL for å gjøre endringer. Du koder en "migration" slik at du kan rulle endringen inn og ut av databasen. Lager du en ny klasse eller et nytt felt så genereres en migration med denne endringen.

Stored procedures er i min verden et antipattern. Businesslogikk hører ikke hjemme i databaselaget.

 

Dersom du er uenig med designet ORMen lagrer så har de helt sikkert en måte å gjøre overrides på via konfigurasjon. Dette vil selvsagt variere fra en ORM til den neste.

Man må vel fortsatt lage tabellene i SQL ?

Endret 31. januar 2015 av pedero

[Enthroner]

 

Med en god ORM så skal du aldri bruke SQL for å gjøre endringer. [...]

Man må vel fortsatt lage tabellene i SQL ?

 

Ikke hvis ORMen og verktøyene som følger med ee god nok.

 

Skriver aldri SQL i f.eks Ruby on Rails eller C# med Entity Framework. Java har jeg ikke så mye erfaring med mtp ORM men tror Hibernate fortsatt er aktuelt og bra?

[quantum]

Man må vel fortsatt lage tabellene i SQL ?

 

 

 

Noen ganger eksisterer tabellene fra før av, eller man ønsker av andre årsaker ikke at ORM'en oppretter dem. F.eks. hvis en DBA sier at det vil han gjøre selv. Ellers kan godt ORM'en opprette tabellene, de fleste har den funksjonaliteten. Og så må man passe på innstillingene så skjema ikke blir opprettet hver eneste gang systemet starter, da forsvinner jo data....

[quantum]

 

Skriver aldri SQL i f.eks Ruby on Rails eller C# med Entity Framework. Java har jeg ikke så mye erfaring med mtp ORM men tror Hibernate fortsatt er aktuelt og bra?

 

 

I java bruker mange JPA-standarden og f.eks. Hibernate implementerer denne. Hibernate er nok mest utbredt, men EclipeLink - JPA referanseimplementasjonen - er også bra. Litt avhengig av behov hva som er best. Apaches OpenJPA, Kundera mot NoSQL-databaser etc. Men Hibernate har et rikt funksjonsutvalg utover ren ORM, interface til Lucene og NoSQL, og den er også mest utbredt, så det er lettest å finne svar på spørsmål med Hibernate.

 

Hibernate har noen proprietære funksjoner, og mange av disse er nå også tilgjengelige via JPA, så bruk mest mulig ren JPA med Hibernate, og ikke utdaterte, proprietære annotasjoner.

[quantum]

 

Du kan bare designe domenemodellen slik du føler det naturlig, og la mapperen finne ut hvordan modellen best mappes til en database.

 

 

Nei, man må tenke når man designer domeneobjektene også, ikke føle. ORM'en tenker ikke for utvikleren. Man flytter altså modelleringsprosessen et nivå opp fra databasen til domene, som jeg skrev.

[quantum]

Men det jeg er redd for hvis jeg bruker et ORM er at jeg vil ende opp med en dårlig designet database, som det vil være vanskelig å legge til nye funksjoner/felter og tabeller i.

 

 

Er dette et stort problem med ORM ?

 

 

Nei. Det er du som designer databasen og ikke ORM'en, selv om du lar ORM'en generere databasen. I det ene tilfelle designer du databasen med SQL-DDL og i det andre med Java og ORM-annoteringer. Du kan også gå andre veien fra en ferdig database, og la f.eks. Netbeans generere JPA-annoterte klasser. Da ender du opp med antipatternet "anemiske domeneobjekter", eller en masse ekstraarbeid når du endrer skjema.

 

Der hvor du ikke eksplisitt sier hvordan du vil ha det vil ORM'en benytte en default mapping og generere databasen i henhold til det. Det blir sjelden feil, men i noen tilfeller kan det hende du vil ha det annerledes, og for min egen del syns jeg det er greit å annotere eksplisitt, så ser jeg tydelig i javakoden hvordan det er mappet opp. (NB opprinnelig konfigurerte man opp mappingen i Hibernate med xml-filer, det anser jeg som noe arkaisk og utdødd, bruk JPA-annoteringer isteden, medmindre det er viktig å ikke kludre til javakoden med annoteringer)

 

Det er også sånn som Enthroner er inne på - at ORM'en gjør noe av "grunnmursarbeidet" for deg, dvs. implementerer fremmednøkler, indekser og restriksjoner på disse, og det er en fordel.

 

Generelt fjerner ORM'en en god del av "boilerplate"-kodingen ift. database, og det gjør det lettere å videreutvikle og bygge ut. Det blir mere jobb om man koder ren sql/jdbc, og det gir også større muligheter for å gjøre feil.

 

Det fins også andre mer sql/tabell-orienterte rammeverk for å gjøre databasekoding enklere, noen mener jo f.eks. at hele konseptet relasjon/tabell <-> objekt-mapping er dødfødt ... grisen vil liksom ikke fly uansett.

Endret 1. februar 2015 av quantum