Jeg ville spille efter styrkerne ved hvert system.
Aggregerings-, sammenføjnings- og filtreringslogik hører naturligvis til på datalaget. Det er hurtigere, ikke kun fordi de fleste DB-motorer har mere end 10 års optimering til at gøre netop det, men du minimerer de data, der flyttes mellem din DB og webserveren.
På den anden side har de fleste DB-platforme jeg har brugt meget dårlig funktionalitet til at arbejde med individuelle værdier. Ting som datoformatering og strengmanipulation suger bare ind i SQL, du er bedre til at udføre det arbejde i PHP.
Grundlæggende skal du bruge hvert system til det, det er bygget til at gøre.
Med hensyn til vedligeholdelse, så længe opdelingen mellem, hvad der sker, hvor er klar, burde adskillelse af disse til typer af logik ikke forårsage mange problemer og bestemt ikke nok til at udelukke fordelene. Efter min mening handler kodeklarhed og vedligeholdelse mere om konsistens end om at samle al logikken ét sted.
Re:specifikke eksempler...
-
Jeg ved, at det ikke er det, du også henviser til, men datoer er næsten et særligt tilfælde. Du vil sikre dig, at alle datoer genereret af systemet er oprettet enten på webserveren ELLER databasen. At gøre andet vil forårsage nogle lumske fejl, hvis db-serveren og webserveren nogensinde er konfigureret til forskellige tidszoner (jeg har set dette ske). Forestil dig for eksempel, at du har en
createdDatekolonne med standardværdiengetDate()der anvendes ved indsættelse af DB . Hvis du så skulle indsætte en post ved at bruge en dato genereret i PHP (f.eks.date("Y-m-d", time() - 3600), vælg poster, der er oprettet inden for den sidste time, får du muligvis ikke, hvad du forventer. Med hensyn til hvilket lag du skal gøre dette på, vil jeg foretrække, at DB'en, som i eksemplet, lader dig bruge kolonnestandarder. -
For de fleste apps ville jeg gøre dette i PHP. At kombinere fornavn og efternavn lyder enkelt, indtil du indser, at du også har brug for hilsener, titler og melleminitialer derinde nogle gange. Derudover vil du næsten helt sikkert ende i en situation, hvor du vil have brugerens fornavn, efternavn OG en kombineret hilsen + fornavn + efternavn. Sammenkædning af dem på DB-siden betyder, at du ender med at flytte flere data, selvom det egentlig er ret lille.
-
Afhænger. Som ovenfor, hvis du nogensinde vil bruge dem separat, er du bedre tjent med at trække dem ud separat og sammenkæde dem, når det er nødvendigt. Når det er sagt, medmindre de datasæt, du har med at gøre med, er enorme, er der sandsynligvis andre faktorer (som, som du nævner, vedligeholdelse) der har mere betydning.
Et par tommelfingerregler:
- Generering af inkrementelle id'er bør ske i DB.
- Personligt kan jeg godt lide min standard anvendt af DB.
- Når du vælger, skal alt, der reducerer antallet af poster, udføres af databasen.
- Det er normalt godt at gøre ting, der reducerer størrelsen af datasættets DB-side (som med strengeksemplet ovenfor).
- Og som du siger; bestilling, aggregering, underforespørgsler, joinforbindelser osv. bør altid være DB-siden.
- Vi har heller ikke talt om dem, men udløsere er normalt dårlige/nødvendige.
Der er et par centrale afvejninger, du står over for her, og balancen afhænger virkelig af din ansøgning.
Nogle ting bør bestemt-hver gang-altid gøres i SQL. Udelukker nogle undtagelser (såsom dato-tinget) for mange opgaver, SQL kan være meget klodset og kan efterlade dig med logik på afveje steder. Når du søger i din kodebase efter referencer til en specifik kolonne (for eksempel), er det let at gå glip af dem, der er indeholdt i en visning eller lagret procedure.
Ydeevne er altid en overvejelse, men afhængigt af din app og det specifikke eksempel er det måske ikke så stort. Dine bekymringer om vedligeholdelse og sandsynligvis meget gyldige og nogle af de præstationsfordele, jeg har nævnt, er meget små, så pas på med for tidlig optimering.
Hvis andre systemer har direkte adgang til DB'en (f.eks. til rapportering eller import/eksport), vil du drage fordel af at have mere logik i DB'en. For eksempel, hvis du ønsker at importere brugere direkte fra en anden datakilde, er noget som en e-mailvalideringsfunktion implementeret i SQL.
Kort svar:det kommer an på. :)