Hvilket språk for å lage enkel CMS?

[PhelpsTransposed]

Hei!

 

Tenkte å lage et CMS/en blogg fra scratch for å få litt øving i systemutvikling og databaser, men lurer på hvilket språk som er mest hensiktsmessig å bruke, evt hva som skiler de ulike språkene fra hverandre.

 

Er det best med php+html+css? Web2python? Ruby on rails? Django? Java?

[Runar]

Personlig ville jeg gått for Ruby on Rails. Men, hvis det er veldig viktig å «snakke» direkte med databasen, er det kanskje ikke det beste valget.

 

Litt pirk, men HTML og CSS kommer du deg ikke unna. Det må du bruke, selv om du går for noe annet enn PHP.

[PhelpsTransposed]

Skulle inn for å redigere nå hehe. Tusen takk for svar.

 

Lest litt på cakephp som jeg ser er php varianten av ruby on rails, og skjønner jo tegninga, men nå er bekymringa om det blir litt for "on rails" og litt for lite øving på f.eks sql og databaser om jeg bruke cakephp/RoR - som du forsåvidt var inne på.

 

Hvor mye "sparer" jeg ved å bruke ruby on rails/cakephp vs å f.eks bare skrive i PHP selv. Kan det tenkes at det er lurt å skrive i php fremfor cakephp for å få mer læringsutbytte?

[Hieronymus]

Jeg ville anbefale deg å titte litt på det Java/Scala-baserte rammeverket Play!

 

http://www.playframework.org/

 

---

Hieronymus

[_dundun_]

Om du skal lære deg database bør du gå for et system som lar deg bruke stored procedures, da dette lærer deg å kode "skikkelig" mot database med en gang. SQL har ingenting i et program å gjøre.

[Terrasque]

"Ask 10 web developers what the best tool is, and you get 15 different answers"

 

Det er mange valg. Personlig baserer jeg meg på python, og tools jeg oftest bruker er Django, MySQL, jQuery og SASS (for CSS).

Endret 22. mars 2012 av Terrasque

[Wattengård]

Om du skal lære deg database bør du gå for et system som lar deg bruke stored procedures, da dette lærer deg å kode "skikkelig" mot database med en gang. SQL har ingenting i et program å gjøre.

Å... Du er en sånn en...

[Hieronymus]

Om du skal lære deg database bør du gå for et system som lar deg bruke stored procedures, da dette lærer deg å kode "skikkelig" mot database med en gang. SQL har ingenting i et program å gjøre.

 

SQL har ingenting i et program å gjøre sier du. Da kan jeg fortelle deg at logikk iallefall ikke har noe i persisteringslaget å gjøre.

 

---

Hieronymus

[_dundun_]

Om du skal lære deg database bør du gå for et system som lar deg bruke stored procedures, da dette lærer deg å kode "skikkelig" mot database med en gang. SQL har ingenting i et program å gjøre.

 

SQL har ingenting i et program å gjøre sier du. Da kan jeg fortelle deg at logikk iallefall ikke har noe i persisteringslaget å gjøre.

 

---

Hieronymus

 

SQL har ingenting i koden å gjøre er å sette det på spissen, men jeg mener definitivt at man bør prøve å standardisere databasekallene best mulig ved å bruke SP der det passer seg seg sånn.

 

Men kan være enig med deg i at forretningslogikken lever best i koden.

[Hieronymus]

Men kan være enig med deg i at forretningslogikken lever best i koden.

 

Jeg jobber til daglig med systemer som fortsatt bruker stored procedures, og det hender rett som det er at jeg må endre / legge til funksjonalitet i disse. Og det må jeg gjøre så lenge kundene har slike systemer.

 

Min motstand mot bruk av stored procedures bunner ut i at jeg synes det er veldig tungvindt å teste dem, sammenlignet med kode i andre lag av applikasjonen.

 

Jeg har vært med å vedlikeholde hundretusenvis av linjer med forretningslogikk i stored procedures og packages i Oracle, og har for lengst mistet oversikten over hvor mye tid jeg har brukt på å lete etter bugs i slik kode.

 

I prosjekter de siste par-tre årene har jeg omtrent ikke toucha SQL og PL/SQL, da jeg for det meste jobber med kode som aksesserer databasen gjennom et ORM-lag.

 

---

Hieronymus

[Sokkalf™]

Gjorde samme øvelse selv (eller, den er vel fortsatt pågående, egentlig), men mest for å oppdatere meg litt på HTML(5) og CSS.

 

Bruker Java til vanlig, men tenkte å prøve noe nytt, og gikk derfor for Python og Django (Kjører det hele på JVMen med Jython). Syns Django var veldig enkelt å komme i gang med, det går kjapt å lage noe som funker.

[torbjørn marø]

SQL har ingenting i koden å gjøre er å sette det på spissen, men jeg mener definitivt at man bør prøve å standardisere databasekallene best mulig ved å bruke SP der det passer seg seg sånn.

 

Men kan være enig med deg i at forretningslogikken lever best i koden.

 

Stored procedures eksistserer først og fremst som en forsvarsmekanisme som databaseadministratorer bruker for å beskytte databasen sin mot ubrukelige programmerere som skriver dårlig SQL. Denne modellen har vi nå heldigvis beveget oss bort fra, og da er SP kun nyttig i helt spesielle tilfeller hvor man trenger nærhet til dataene og kraften som ligger i databasemotoren.

Endret 3. april 2012 av torbjørn marø

[GeirGrusom]

Stored procedures eksisterer fordi det kan enkelt abstrahere og skjule databaselogikken, samt føre til spørringer som utføres raskere.

SQL har ingenting i koden å gjøre er å sette det på spissen, men jeg mener definitivt at man bør prøve å standardisere databasekallene best mulig ved å bruke SP der det passer seg seg sånn.

 

Men kan være enig med deg i at forretningslogikken lever best i koden.

 

Stored procedures eksistserer først og fremst som en forsvarsmekanisme som databaseadministratorer bruker for å beskytte databasen sin mot ubrukelige programmerere som skriver dårlig SQL. Denne modellen har vi nå heldigvis beveget oss bort fra, og da er SP kun nyttig i helt spesielle tilfeller hvor man trenger nærhet til dataene og kraften som ligger i databasemotoren.

Hvis du skriver ubrukelig SQL spiller det ingen rolle om du bruker SP eller ikke. SP er snakk om abstraksjon; ikke funksjonalitet.

[_dundun_]

Stored procedures eksistserer først og fremst som en forsvarsmekanisme som databaseadministratorer bruker for å beskytte databasen sin mot ubrukelige programmerere som skriver dårlig SQL. Denne modellen har vi nå heldigvis beveget oss bort fra, og da er SP kun nyttig i helt spesielle tilfeller hvor man trenger nærhet til dataene og kraften som ligger i databasemotoren.

 

Nope.

 

Det finnes masse gode grunner til å benytte SP. Jeg jobber for tiden med en del enterprisesoftware der vi har flere systemer som snakker med samme database. Ved å benytte SP som eneste tilgangsmetode til datene sikrer vi at flere applikasjoner kan snakke med samme database uten at inkonsistent koding skader dataintegriteten.

 

Som det sies over her; SP er ingen beskyttelse mot dårlig SQL, siden det rett og slett er SQL. Det det imidlertid er er en strålende metode for å sikre konsistente data inn og ut fra en database når man har en mer kompleks som ikke tillater "SELECT * FROM tabell".

 

For å gi et eksempel på en kodesnutt jeg nettopp skrev:

 

"Hent hovedelement fra tabell A samt alle tags relatert til dette elementet fra tabell B og standarddata fra tabell C. Bruk angitt språk dersom tags finnes på dette, hvis ikke bruk fallback-språket. Om flere tags finnes på samme språk og med samme nøkkel, bruk den nyeste. Dersom enkelte nøkkeltags ikke er definert pga dårlige inndata, sett inn default value".

 

Denne spørringen skal kjøres fra flere systemer implementert i forskjellige språk.

 

Med SP kan jeg si "Getelement @param_1 @param_2" i alle systemene og føle meg trygg på at jeg får de samme dataene.

 

Men om man bare jobber med databaseaksess der en enkeltkommando kan gjøre hele jobben stiller det seg selvsagt annerledes, da er det greit nok å ha spørringene direkte i koden, selv om man mister et lag med datasikring. Hvert verktøy til sitt bruk.

 

Der SP begynner å bli farlig er når man bygger inn forretningslogikken og ren funksjonalitet som hører hjemme i programmet (eller i regler). En database skal ikke kjøre lønn eller regne areal, men den skal returnere riktige data og ta seg av datalogikk.

 

(Bra blogg forresten, herved lagt til i Reader )

Endret 3. april 2012 av kvasbo

[torbjørn marø]

Det finnes masse gode grunner til å benytte SP. Jeg jobber for tiden med en del enterprisesoftware der vi har flere systemer som snakker med samme database. Ved å benytte SP som eneste tilgangsmetode til datene sikrer vi at flere applikasjoner kan snakke med samme database uten at inkonsistent koding skader dataintegriteten.

Å bruke databasen som et integrasjonspunkt ser mange også på som et anti-pattern (meg inkludert). Men det har i lange tider vært en vanlig praksis mange steder. Er du i en slik situasjon så blir SP din eneste mulighet til å sikre konsistent forretningslogikk. Dilemmaet er da altså at SQL sjelden er det beste språket for å beskrive slik logikk.

 

Som det sies over her; SP er ingen beskyttelse mot dårlig SQL, siden det rett og slett er SQL. Det det imidlertid er er en strålende metode for å sikre konsistente data inn og ut fra en database når man har en mer kompleks som ikke tillater "SELECT * FROM tabell".

Poenget mitt kom kanskje ikke helt frem. Vanslig praksis blant databaseadministratorer fra fossefall-tiden var å fjerne tilgangen til alt annet enn SP for alle andre enn seg selv, og så tilby et SP-lag som alle apper og utviklere måtte bruke. Og det var databaseekspertene som skrev SP'ene, ikke utviklerne. SP var altså verktøyet de brukte for å hindre at utviklerne fikk rotet med SQL overhodet.

 

Min oppfatning er at det er dette som gjorde SP'teknologien populær. Selvsagt har det bruksområder (som jeg påpekte), men først og fremst (hevder jeg) har det vært en beskyttelsesmekanisme.

 

.. som førte til at databaseadministratorene ble en flaskehals for å få levert funksjonalitet. Behov måtte spesifiseres og leveres over muren til en annen avdeling som så kodet SP'ene. Er så glad det ikke finnes så mange slike steder lengre.

 

(Bra blogg forresten, herved lagt til i Reader )

Takk ;D

[GeirGrusom]

Helt enig i det du sier. Det eneste jeg reagerte på var utsagnet om at SP var for n00bs.

 

Jeg synes ikke at SQL har noe å gjøre i forretningslogikk overhode. SP er én måte å sørge for dette på.

[_dundun_]

 

Å bruke databasen som et integrasjonspunkt ser mange også på som et anti-pattern (meg inkludert). Men det har i lange tider vært en vanlig praksis mange steder. Er du i en slik situasjon så blir SP din eneste mulighet til å sikre konsistent forretningslogikk. Dilemmaet er da altså at SQL sjelden er det beste språket for å beskrive slik logikk.

 

 

Det er ikke alltid man er så heldig at man kan unngå å bruke antipatterns

 

 

Poenget mitt kom kanskje ikke helt frem. Vanslig praksis blant databaseadministratorer fra fossefall-tiden var å fjerne tilgangen til alt annet enn SP for alle andre enn seg selv, og så tilby et SP-lag som alle apper og utviklere måtte bruke. Og det var databaseekspertene som skrev SP'ene, ikke utviklerne. SP var altså verktøyet de brukte for å hindre at utviklerne fikk rotet med SQL overhodet.

 

Min oppfatning er at det er dette som gjorde SP'teknologien populær. Selvsagt har det bruksområder (som jeg påpekte), men først og fremst (hevder jeg) har det vært en beskyttelsesmekanisme.

 

 

Ser problemet. Ideelt sett burde jo dette også funke, dersom spesifikasjonen er god nok (eller man sitter i samme agile-team), men i virkeligheten vil det neppe fungere uten at utviklerne også tar seg av SP.

 

 

.. som førte til at databaseadministratorene ble en flaskehals for å få levert funksjonalitet. Behov måtte spesifiseres og leveres over muren til en annen avdeling som så kodet SP'ene. Er så glad det ikke finnes så mange slike steder lengre.

 

Når det er sånn er det jo litt krise. Der jeg jobber (meget stort norsk oljeselskap) står utviklerne for hele greia og lever en pakke med deployment scripts som tar seg av både database, kode og evt. andre filer.

[PhelpsTransposed]

Vanvittig interressant diskusjon hittil! Utdanner meg innen IKT så både denne diskusjonen og prosjektet har vært veldig lærerikt hittil. Har kommet så langt at jeg har registreringssystem, login, logout, skrive innlegg, redigere innlegg. Gjort mye feil, og lært en del i selve planleggingsprosessen underveis.

[Wattengård]

Skulle kanskje diskusjonen bli tatt ut av den opprinnelige tråden og inn i egen tråd? Det kan være folk som vil ha interesse av diskusjonen, som ikke blir fenget av det originale spørsmålet... (Rapporterer...)