Lage egen database software?

[Tå.]

Tenkte jeg skulle ta et dypdykk ned i et programmeringsspråk (python), og i den sammenheng har jeg satt meg et delmål som er å lage egen database software. Greit nok at jeg finner opp hjulet på nytt, men det vil være et skreddersydd hjul tilpasset mine behov.

 

Systemet jeg har i dag baserer seg på rundt 120 separate databaser (identiske og i access) med ulikt antall registreringer. Hver registrering har verdier som navn, adresse, telefon epost osv. Har en "form" for registreringer og en "form"for å printe ut utvalgte verdier. I tillegg har jeg en rapport for å printe ut informasjon om alle kunder.

 

Er også mye informasjon jeg skulle hatt, som jeg for øyeblikket ikke har tilgjenglig(er ihvertfall ikke synlig). For eks skulle jeg likt å vite når(dato) en registrering ble registrert, og når den sist ble endret. Er det noen enkel løsning for dette i access?

Kunne også muligens tenke meg å gjøre det hele nettbasert.

 

Men tilbake til hovedpoenget. Vil dette være en overkommelig oppgave å utføre gjennom python?

[Hieronymus]

Tenkte jeg skulle ta et dypdykk ned i et programmeringsspråk (python), og i den sammenheng har jeg satt meg et delmål som er å lage egen database software. Greit nok at jeg finner opp hjulet på nytt, men det vil være et skreddersydd hjul tilpasset mine behov.

 

Systemet jeg har i dag baserer seg på rundt 120 separate databaser (identiske og i access) med ulikt antall registreringer. Hver registrering har verdier som navn, adresse, telefon epost osv. Har en "form" for registreringer og en "form"for å printe ut utvalgte verdier. I tillegg har jeg en rapport for å printe ut informasjon om alle kunder.

 

Er også mye informasjon jeg skulle hatt, som jeg for øyeblikket ikke har tilgjenglig(er ihvertfall ikke synlig). For eks skulle jeg likt å vite når(dato) en registrering ble registrert, og når den sist ble endret. Er det noen enkel løsning for dette i access?

Kunne også muligens tenke meg å gjøre det hele nettbasert.

 

Men tilbake til hovedpoenget. Vil dette være en overkommelig oppgave å utføre gjennom python?

 

Jeg skjønner ikke helt hva du er ute etter. Når du sier "database software" så tenker jeg automatisk MySQL, Postrgres, Oracle, men når jeg leser resten av innlegget ditt, så skjønner jeg jo at du ikke kan mene det. Faktisk skjønner jeg ikke hva du mener i det hele tatt, og jeg begynner å lure på om du skjønner noe, siden du lagrer data i 120 separate, men identiske databaser. Jeg vil anbefale deg å lese deg opp på databaseteori.

[tomsi42]

Jeg tror også at det å lære seg riktig bruk av databaser er en god ide.

 

Deretter kan det godt hende at det er riktig å bruke Python og f.eks. Postgresql for å lage løsningen riktig.

[GeirGrusom]

Er også mye informasjon jeg skulle hatt, som jeg for øyeblikket ikke har tilgjenglig(er ihvertfall ikke synlig). For eks skulle jeg likt å vite når(dato) en registrering ble registrert, og når den sist ble endret. Er det noen enkel løsning for dette i access?

Det er utvikleren sin oppgave å lagre relevant data i en database. Ikke noe annet enn det du registrerer av data vil havne der. Hvis du vil vite når en rad ble lagt til, så må du ha et felt for det.

Created datetime not null default(date())

Hvis det ikke finnes, så er det ikke stort å gjøre med det annet enn å legge det til.

 

Men jeg forstår ikke helt hva du vil gjøre... databasesoftware?... det høres ut som du vil lage en egen databasemotor til å begynne med, men etterpå virker det mer som du skal konsumere data fra en rekke merkelige datakilder.

[Tå.]

Jeg er ikke noen ekspert på databaser, hadde IT på videregående for 10 år siden. Der lærte jeg litt grunnleggende access, men husker langt ifra alt. Godt mulig at det er mer hensiktsmessig å lagre alt i en database, men med 11k registreringer og begrenset med kunnskap om access ville det blitt et lite brukervennlig system.

 

 

Uansett. Jeg vil både lage en databasemotor(tilpasset mine behov) og deretter konsumere en rekke merkelige datakilder om det gir noe mening. Jeg ønsker også å modifisere mitt nåværende system med for eks nevnte datoendring. Om noen er ønsker å analysere "malen" jeg bruker og gi meg noen innspill så hadde det vært flott.

 

Litt mer om systemet jeg har i dag. De brukes i direkte markedsføring. Databasen "gamer.no" har hundre kunder. Når vi får nye kunder fra gamer.no, registreres de i databasen kalt gamer.no. Hver gang vi har aktivitet på gamer.no printer jeg ut adresse til hver kunde (bruker her et form vindu) på et a4 ark og sender dem informasjonen.

 

 

Created datetime not null default(date())

Hvis det ikke finnes, så er det ikke stort å gjøre med det annet enn å legge det til.

 

La til en rad som registrerer systemdato som "default value" på nye registreringer. Har dog ikke peiling hvordan man legger inn en sånn kode for å få ønsket resultat.

[zotbar1234]

Uansett. Jeg vil både lage en databasemotor(tilpasset mine behov)

 

Med mindre du faktisk ønsker å trene på å implementere en database med ACID-egenskaper i Python (en interessant og nyttig øvelse), hva er galt med å bruke sqlalchemy + hvilken db-backend som måtte passe?

 

og deretter konsumere en rekke merkelige datakilder om det gir noe mening.

 

Så, du trenger et skjema og noe som masserer på datakildene for å befolke dette skjemaet.

 

Jeg ønsker også å modifisere mitt nåværende system

 

Så, lage nytt eller modifisere eksisterende?

[Tå.]

Med mindre du faktisk ønsker å trene på å implementere en database med ACID-egenskaper i Python (en interessant og nyttig øvelse), hva er galt med å bruke sqlalchemy + hvilken db-backend som måtte passe?

 

Som det kort ble nevt, ønsker å prøve på dette fordi jeg vil ha noe å strekke meg etter når jeg prøver å lære meg python. Sikkert enklere å gjøre det med andre verktøy, men en liten utfordring har jeg ikke noe imot.

 

Så, lage nytt eller modifisere eksisterende?

 

Jeg antar at det vil ta en god del tid å lage et nytt system(spørs om jeg i det hele tatt kommer i mål). I mellomtiden vil jeg da gjøre små endringer i mitt nåværende system.

[zotbar1234]

Som det kort ble nevt, ønsker å prøve på dette fordi jeg vil ha noe å strekke meg etter når jeg prøver å lære meg python. Sikkert enklere å gjøre det med andre verktøy, men en liten utfordring har jeg ikke noe imot.

 

Jeg tror en database er en litt vel stor utfordring å strekke seg etter. Det vil ta deg mye tid selv å komme på høyde med sqlite (som ikke engang har ACID-egenskapene).

 

Jeg antar at det vil ta en god del tid å lage et nytt system(spørs om jeg i det hele tatt kommer i mål). I mellomtiden vil jeg da gjøre små endringer i mitt nåværende system.

 

Uten å vite mye mer om hvordan db-skjema ser ut og hva du har tenkt å populere det med/bruke skjema til, blir det vanskelig å råde noe konkret.

 

Imidlertid, mitt første råd må likevel gå i retning sqlite + sqlalchemy. Det er en forholdsvis lavt hengende frukt iallfall for å teste ut ideer. Oppsettet med database på fil med sqlite er minimalt, og sqlalchemy vil hjelpe deg å migrere til en saklig database siden.

 

En annen mulighet (enda lavere frukt) er å bruke pickle direkte. Du slipper å styre med databaser overhodet, og det er trivielt å serialisere en vilkårlig komplisert objektstruktur til en (pickle)fil.

 

Nok en mulighet er å bruke json/xml til serialisering. Nå vil hverken dette eller pickle være en database, men med 11k oppføringer spiller det omtrent ingen rolle hva du velger, siden datamengden er forsvinnende liten.

 

Jeg har fremdeles ikke fått det helt klart hva du ønsker å implementere eksakt i Python. Vil du lage et program som masserer data og dytter disse i en database (være det ny eller eksisterende), eller vil du faktisk lage en forenklet variant av det som Oracle/MySQL/PostgreSQL tilbyr i dag?

[Djn]

Jeg har raskt skissert opp en vanlig struktur (temmelig forenklet). Hvilke av delene under er det du vil skrive? Hvis du tenker på RDBMS-biten, så er jeg enig med zotbar i at det blir temmelig mye arbeid hvis du vil gjøre det ordentlig, og at det nok er lurere å bruke en eksisterende database (sqlite er som sagt veldig grei) - så lærer du deg å bruke både SQL og python sine database-verktøy mens du er i gang.

 

Det sagt: Du kan nok lage noe som ligner ved kreativ bruk av lister og dictionaries i python (som du så kan lagre til disk med pickle når du lukker programmet); det er nok også god øvelse i datastrukturer og slikt.

 

 

(Og om det er noen MVC-fans her: Dette er mer three-tier, men tenk dere gjerne at grensesnittet er MVC internt.)

Endret 25. september 2012 av Djn

[GeirGrusom]

Kan normalt sett være en god idé å abstrahere bort SQL også. Fordelen er at man kan bytte provider og tilogmed bruke NoSQL databaser uten å måtte endre forretningslogikk.

[Djn]

Kan normalt sett være en god idé å abstrahere bort SQL også. Fordelen er at man kan bytte provider og tilogmed bruke NoSQL databaser uten å måtte endre forretningslogikk.

 

Forsåvidt sant, men kanskje litt overkill for det prosjektet han holder på med her.

[zotbar1234]

Kan normalt sett være en god idé å abstrahere bort SQL også. Fordelen er at man kan bytte provider og tilogmed bruke NoSQL databaser uten å måtte endre forretningslogikk.

 

Beklager trådkuppingen -- hvordan tenkte du å abstrahere bort SQL? sqlalchemy-stil eller noe enda mer finurlig?

[Djn]

Kan normalt sett være en god idé å abstrahere bort SQL også. Fordelen er at man kan bytte provider og tilogmed bruke NoSQL databaser uten å måtte endre forretningslogikk.

 

Beklager trådkuppingen -- hvordan tenkte du å abstrahere bort SQL? sqlalchemy-stil eller noe enda mer finurlig?

 

Jeg antar man kan skrive en ORM av noe slag som presenterer de samme objektene til python, og støtter både SQL og NoSQL. Hvorvidt det alltid vil være effektivt er noe annet, det er tross alt noe forskjell på de to.

[GeirGrusom]

Kan normalt sett være en god idé å abstrahere bort SQL også. Fordelen er at man kan bytte provider og tilogmed bruke NoSQL databaser uten å måtte endre forretningslogikk.

 

Beklager trådkuppingen -- hvordan tenkte du å abstrahere bort SQL? sqlalchemy-stil eller noe enda mer finurlig?

 

Jeg antar man kan skrive en ORM av noe slag som presenterer de samme objektene til python, og støtter både SQL og NoSQL. Hvorvidt det alltid vil være effektivt er noe annet, det er tross alt noe forskjell på de to.

Min mening er at funksjon på lang vei trumfer effektivitet. Hvis det er effektivitet du er ute etter, så er Python feil valg i utgangangspunktet.

 

Nå har jeg mest erfaring med C#, men der har man en litt finurlig funksjonalitet som kalles Expression Trees. Det som er greia med expressiontrees, er at kompilatoren kan ved en noen tilfeller gi tilbake resultatet av et lambdauttrykk som et expression-tree. Dette fører til at du kan benytte lambdauttrykk som en språkmessig måte å spørre ut en database på og det vil da være fullstendig likegyldig hva slags databaselag som ligger under, ettersom expression tree lett kan uttrykkes som SQL, og kan lett overføres til NoSQL databaser. Noe ORM funksjonalitet rundt dette må en da legge til.

 

eksempelvis:

 

public abstract class DataSource
{
 public Get<TRecordType>(Expression<Func<TRecordType, bool>> expression)
 {
   //.. oversett expression til SQL, returner fra databasemotoren
   // dersom dette er en NoSQL database, så kan ihvertfall under C# de ofte bruke slike uttrykk fra før
   // kan også lett lage en in-memory mock database for integrasjonstesting
 }
}
...
void SomeTest()
{
 MyTable table = DataSource.Get<MyTable>(item => item.Id == 100);
}

 

Fordelen her er at databasen er fullstendig koblet vekk fra forretningslogikken, samt at en får sterk typing på databasefelt i spørringer, og et viktig poeng: ingen SQL i forretningslogikken!

[zotbar1234]

Min mening er at funksjon på lang vei trumfer effektivitet. Hvis det er effektivitet du er ute etter, så er Python feil valg i utgangangspunktet.

 

Rrrright. Men hvis vi lar den ligge.

 

Nå har jeg mest erfaring med C#, men der har man en litt finurlig funksjonalitet som kalles Expression Trees. Det som er greia med expressiontrees, er at kompilatoren kan ved en noen tilfeller gi tilbake resultatet av et lambdauttrykk som et expression-tree. Dette fører til at du kan benytte lambdauttrykk som en språkmessig måte å spørre ut en database på og det vil da være fullstendig likegyldig hva slags databaselag som ligger under, ettersom expression tree lett kan uttrykkes som SQL, og kan lett overføres til NoSQL databaser. Noe ORM funksjonalitet rundt dette må en da legge til.

 

Aha. Så abstraksjonen (av SQL) blir i dette tilfellet expression trees, og de må du selv oversette til den SQL-dialekten (evt. noe annet). Man har riktignok ast-modulen i Python, men det ville aldri ha falt meg inn å gjøre det på den måten, fordi at:

 

public abstract class DataSource
{
 public Get<TRecordType>(Expression<Func<TRecordType, bool>> expression)
 {
 }
}
...
void SomeTest()
{
 MyTable table = DataSource.Get<MyTable>(item => item.Id == 100);
}

 

... lurer jeg på hvordan ser for langt mindre trivielle uthentingsoperasjoner (de som krever flere ikke-trivielle joins, eksempelvis).

 

Fordelen her er at databasen er fullstendig koblet vekk fra forretningslogikken, samt at en får sterk typing på databasefelt i spørringer, og et viktig poeng: ingen SQL i forretningslogikken!

 

Det får man til uansett hva man legger seg på av abstraksjon (expression trees, sitt eget minispråk, sqlalchemy -- bare det er gjemt unna forretningslogikken bak passende beskrivende funksjonskall).

[GeirGrusom]

 

Aha. Så abstraksjonen (av SQL) blir i dette tilfellet expression trees, og de må du selv oversette til den SQL-dialekten (evt. noe annet). Man har riktignok ast-modulen i Python, men det ville aldri ha falt meg inn å gjøre det på den måten, fordi at:

 

public abstract class DataSource
{
 public Get<TRecordType>(Expression<Func<TRecordType, bool>> expression)
 {
 }
}
...
void SomeTest()
{
 MyTable table = DataSource.Get<MyTable>(item => item.Id == 100);
}

 

... lurer jeg på hvordan ser for langt mindre trivielle uthentingsoperasjoner (de som krever flere ikke-trivielle joins, eksempelvis).

Det spørs egentlig hvor mye arbeid en vil legge i det. Joins i seg selv er ikke noe problem da det kommer fint ut av objektmodellen og expression tree hvordan dette skal gjøres.

 

Fordelen her er at databasen er fullstendig koblet vekk fra forretningslogikken, samt at en får sterk typing på databasefelt i spørringer, og et viktig poeng: ingen SQL i forretningslogikken!

 

Det får man til uansett hva man legger seg på av abstraksjon (expression trees, sitt eget minispråk, sqlalchemy -- bare det er gjemt unna forretningslogikken bak passende beskrivende funksjonskall).

Javisst! Expression trees var bare et eksempel.

[Gjest Slettet+9871234]

Imidlertid, mitt første råd må likevel gå i retning sqlite + sqlalchemy. Det er en forholdsvis lavt hengende frukt iallfall for å teste ut ideer. Oppsettet med database på fil med sqlite er minimalt, og sqlalchemy vil hjelpe deg å migrere til en saklig database siden.

 

Enig om du faller ned på Python. Litteratur http://withdjango.com/

 

Se også: Python and databases. Good enough is sometimes best

 

Bruker du PHP på nettet, finnes det sikkert allerede et CMS system med en databaseløsning.

 

Det er hevdet at enhver site kan utvikles i for eksmpel drupal som har en innebygd databaseløsning allerede.

 

Systemet jeg har i dag baserer seg på rundt 120 separate databaser (identiske og i access) med ulikt antall registreringer. Hver registrering har verdier som navn, adresse, telefon epost osv. Har en "form" for registreringer og en "form"for å printe ut utvalgte verdier. I tillegg har jeg en rapport for å printe ut informasjon om alle kunder.

 

Mener du databaser eller tabeller?

Endret 27. september 2012 av Slettet+9871234

[j0achim]

Om du skulle tenke tanken å leke deg med C# kan jeg virkelig anbefale LINQ + Castle Activerecord som lager meget sexy kode om du ligger ved litt godvilje

[Terrasque]

Med mindre du faktisk ønsker å trene på å implementere en database med ACID-egenskaper i Python (en interessant og nyttig øvelse), hva er galt med å bruke sqlalchemy + hvilken db-backend som måtte passe?

 

Som det kort ble nevt, ønsker å prøve på dette fordi jeg vil ha noe å strekke meg etter når jeg prøver å lære meg python. Sikkert enklere å gjøre det med andre verktøy, men en liten utfordring har jeg ikke noe imot.

 

Oversatt til mekaniker-verdnen (Preposition: F16 jagerfly blir gitt vekk, helt gratis, til alle som spør) :

 

"Hei, jeg har nettopp lært meg litt sveising og sliping, og da syns jeg at jeg bør lage et jetfly. Føler jeg vil ha noe å strekke meg mot. Jeg vet jeg kan få gratis fly som er utrolig bra, men jeg er spesiell, og føler jeg trenger et fly med 14 vinger."

 

11k rader er peanuts. Det er ingenting, null, og niks. Det er et sandkorn ved Dovrefjell. Selv de elendigste gratis tilgjengelige databasene vil ikke ha noen problemer i det hele tatt med det. Og du har fritt valg på øverste hylle når det gjelder frie databasemotorer.

 

Ditt mål er ikke å bygge et jetfly. Ditt mål er å frakte $foo fra A til B. Fokuser på det. Det du prøver på er mer eller mindre "jeg kjenner ikke kontrollsystemet for eksisterende jets, så jeg bare lager min egen jet istedet" - bad idea.

 

De brukes i direkte markedsføring. Databasen "gamer.no" har hundre kunder. Når vi får nye kunder fra gamer.no, registreres de i databasen kalt gamer.no. Hver gang vi har aktivitet på gamer.no printer jeg ut adresse til hver kunde (bruker her et form vindu) på et a4 ark og sender dem informasjonen.

 

*kremt* Når det er sagt, hvis du vil bruke SQL så bør du kanskje lese litt på hvordan man bør dytte inn data i de F.eks der så er en database for hver helt feil måte å gjøre det på

 

Det som er vanlig er å ha en tabell med hver leverandør (f.eks id, navn, web adresse, evt andre ting som man vil ha om leverandøren), og så i kunde listen bare referere til id'en for leverandøren (aka Foreign key).

[The Jackal]

+1 til Terrasque!

 

Jeg har selv i underkant av 10 års erfaring med .NET, databaser og utvikling, er sertifisert MCPD (like it matters )++. Jeg hadde aldri verden begynt med å lage mitt eget databasesystem. Er faktisk ikke sikker på om jeg hadde vært i stand til å gjøre det skikkelig for den saks skyld. Det er ikke helt rett fram å lage noe ACID system...leave it to the pros!