Seleziona formati di output personalizzati dal database con SQL

1

Sto pensando di creare una semplice applicazione per il servizio di riposo, e attualmente sto decidendo l'architettura. Ho deciso che voglio scrivere il livello intermedio in più lingue, in modo che sia facile da implementare / integrare con una gamma quanto più ampia possibile di sistemi.

A causa della necessità di trasferire il codice in più lingue, voglio mantenere la logica del livello intermedio il più semplice possibile, per alleviare lo sforzo di codifica coinvolto.

Sto pensando di inserire più codice possibile in SQL. Ad esempio, tradizionalmente, potrei selezionare alcuni dati dal database, quindi scorrere l'array di risultati e elaborarli ulteriormente prima di inviarli come risposta ben formata, come forse alcuni HTML derivati dai dati.

Tuttavia, dato che voglio che il livello intermedio sia il più semplice possibile, preferirei fare tutto il processo come SQL. Ho preparato istruzioni SQL che selezionano dai miei risultati concatenando e utilizzando aggregati di gruppo per elementi ripetuti. Tutto sembra funzionare bene, ma ho un dubbio insignificante che ho lasciato la prenotazione.

Sono preoccupato di non aver visto questo genere di cose, quindi forse c'è una buona ragione per cui non ho pensato.

La mia domanda è ...

È una cattiva idea scrivere una logica di formattazione complessa in SQL invece del codice dell'applicazione?

In termini di ...

  1. prestazioni
  2. manutenzione del codice
  3. limitazioni della lingua
  4. qualsiasi altra cosa

NB. Non voglio usare PL_SQL o qualcosa del genere, mi interessa solo usare i comandi SQL di base per ottenere la mia formattazione, perché voglio che il codice del database sia portatile anche tra diversi database

    
posta Billy Moon 04.03.2014 - 19:44
fonte

3 risposte

2

Ciò che descrivi è abbastanza comune. Non userei SQL per generare una formattazione HTML reale presentata all'utente. Ma non c'è niente di sbagliato nel mettere un po 'di pesante sollevamento sul server del database. Infatti, c'è un scuola di pensiero che lo incoraggia. Gli esempi possono essere la formattazione di date e numeri o anche l'utilizzo di stored procedure per i calcoli geografici. Devi solo essere a conoscenza di eventuali problemi di prestazioni se le tue query iniziano a diventare troppo complesse ed essere pronto a profilare loro se si presentano. Molti programmatori, in particolare quelli abbastanza nuovi nei database, sottostimeranno di molto il tipo di carico di lavoro che un DBMS ben strutturato può gestire.

Addendum: Personalmente, preferisco la maggior parte della logica per essere in codice perché sono un programmatore ed è quello con cui lavoro. Ma ci sono casi in cui si vuole fare più affidamento sul server SQL. Il tuo potrebbe essere uno di loro.

    
risposta data 04.03.2014 - 20:20
fonte
1
In terms of...

1. performance
2. maintenance of code
3. limitations of language
4. anything else
  1. Non vedo grossi problemi a meno che le tue funzioni di formattazione non diventino molto complesse. Suppongo che potrebbe accadere. Ho fatto cose simili e non ho mai avuto problemi con le prestazioni, ma potrebbe ancora succedere.
  2. La tua logica di formattazione si trova in un punto centrale. Non è una brutta cosa.
  3. Sei limitato alle funzioni fornite dal tuo database. Questo potrebbe o non potrebbe essere un problema.

Questa non è una cattiva idea. Ti dà la possibilità di avere client diversi che ottengono lo stesso tipo di risultati e non richiede di scrivere un componente di formattazione separato.

Suggerirei che, se lo fai, hai una vista base che presenta i dati, non formattata. In questo modo, puoi scrivere diverse viste su quella vista con una logica di formattazione diversa, poiché inizi a richiedere output formattati in modo diverso (testo, HTML, HTML per dispositivi mobili, XML, ecc.)

Se si decide che tutta la formattazione nel database non è così grande, è possibile modificare il database in modo da formattare l'output come XML e quindi utilizzare un XSLT in molti client per trasformarlo nel formato di destinazione. In tal caso, tutto ciò che devi fare è eseguire XSLT nel tuo client (a condizione che le molte lingue diverse possano gestire XML e XSL).

    
risposta data 04.03.2014 - 20:52
fonte
0

Hai scritto che vuoi

write complex formatting logic in SQL

ma poi

I don't want to use PL_SQL or anything like that, I am only interested in using very basic SQL commands to achieve my formatting as I want the database code to be portable between different databases too

Per mia esperienza, non è possibile avere entrambi: o si decide di eseguire una logica di formattazione complessa in SQL o si decide di utilizzare l'SQL portatile, il che significa che non sarà possibile alcuna formattazione complessa. La ragione di ciò è che ANSI SQL supporta solo un piccolo set di funzioni di formattazione delle stringhe, ben lungi dall'essere abbastanza per implementare i requisiti di formattazione reali. Tuttavia, i grandi fornitori di database come Oracle, MS, IBM o Sybase hanno aggiunto abbastanza estensioni proprietarie, specialmente nei dialetti di stored procedure, per consentire cose come il numero personalizzato o la formattazione della data, la generazione di HTML o XML ecc.

    
risposta data 04.03.2014 - 22:07
fonte

Leggi altre domande sui tag