Quali sono gli svantaggi di SQL in JSP, PHP o altri script sul lato server?

Question

Quali sono gli svantaggi di SQL in JSP, PHP o altri script sul lato server?

#1 da (0 voti)

0

Sto lavorando su una base di codice che risale ad almeno 15 anni e probabilmente anche a 20 anni, dove il vecchio codice è ancora funzionale ma include migliaia di JSP pieni di Connection, PreparedStatement, e gli oggetti ResultSet, così come l'SQL codificato, per gestire l'accesso ai dati.

Sì, è doloroso come sembra ... ma la mia domanda specifica è che, dato che è ancora funziona , quali sono tutti gli altri svantaggi delle semplici funzionalità ?

Desidero scrivere una proposta da presentare al proprietario della società, in modo che paghi il denaro per ottenere tutto questo aggiornato agli standard moderni. Posso pensare a molti dei problemi più ovvi, ma da una prospettiva aziendale , quali all'orizzonte si profilano crisi che possono essere evitate solo girando la nave ora ?

[Modifica] Per chiarire, non sto cercando consigli o suggerimenti su quali tecnologie utilizzare. Come una questione di sviluppo del software sto cercando un breve elenco di questioni rilevanti nel 2016 che abbiano un buon senso degli affari , da utilizzare come parte della proposta. Ad esempio, quali sono i "costi nascosti" per questa architettura, quali sono le vulnerabilità e il potenziale danno dall'errore, ecc.

sql architecture coding-standards jsp

posta Andrew 28.12.2016 - 00:04

fonte

1 risposta

Leggi altre domande sui tag sql architecture coding-standards jsp

Collezioni con limite MongoDB Esiste un nome per questa trasformazione della grammatica (o una sua forma più generale)?

score 0 · Accepted Answer

La risposta che stai cercando riguarda principalmente la sicurezza e l'esperienza utente. Ho gestito centinaia di vecchie applicazioni e non è mai una buona cosa avere qualcosa in produzione che temi o non comprenda appieno. Il modo in cui lo vedo:

1 ITS OLD, TECH È DESTINATO AD ESSERE AGGIORNATO. Il software legacy spesso non è solo un problema per lo sviluppatore / manutentore, ma è anche un enorme buco di denaro. I proprietari di aziende finiscono per pagare molto di più per mantenere / sistemare le cose quando si rompono in applicazioni legacy più vecchie a causa di tutte le prove / prove di precisione / prove ed errori che spesso provengono da vecchie applicazioni hogpoged. È spesso un investimento molto migliore per ricostruire l'app utilizzando gli standard attuali. Non solo sarà più facile da mantenere, ma sia il proprietario che lo sviluppatore avranno una certa tranquillità in cui sai se qualcosa si rompe, puoi facilmente risolverlo, invece di passare giorni a rivedere il tuo vecchio codice obsoleto e quindi vecchi e obsoleti modi di aggiustare esso. Spesso capita di trovare le librerie necessarie che potrebbero semplicemente non esistere o essere state estratte dai siti web.

SICUREZZA. Questo è un grande. Il software legacy è spesso insicuro e difficile da applicare. Le pratiche di sicurezza cambiano COSTANTEMENTE, ed è qualcosa che deve essere mantenuta. Molte applicazioni legacy possono fare riferimento a metodi / librerie o librerie vecchie / rotte / non sicure che possono consentire agli hacker di accedere liberamente al proprio database e trovare questi problemi è incredibilmente difficile, risolvendoli, persino peggio. Caso un punto è un cliente di mio annuncio una vecchia applicazione vb.net. C'era una falla nella sicurezza che permetteva a qualcuno di entrare nel sito Web iniettando direttamente in una funzione dell'app datepicker. Le nuove tecnologie sono spesso costruite pensando alla sicurezza e sono molto più facili da testare e mantenere la sicurezza. È più semplice prevenire l'SQL injection, è possibile ottenere certificati SSL molto più semplici e, in caso di problemi, è possibile cercare facilmente Stack o altre risorse per trovare rapidamente una soluzione. Sul software legacy .. potresti cercare giorni per il problema e giorni per la correzione, se ne esiste uno, oppure potresti finire per dedicare un sacco di tempo al denaro per aggiustare qualcosa che non vale la pena aggiustare. Chiediti questo: puoi davvero permetterti di essere hackerato? Perderai tutto? Perderai giorni di lavoro? Sapere che potrebbe accadere in qualsiasi momento per qualsiasi motivo va bene con te? La maggior parte dei proprietari preferirebbe pagare un po 'adesso, invece molto più tardi.
ESPERIENZA UTENTE / PRODUTTIVITÀ: standard e linguaggi più recenti sono più veloci, più efficienti e offrono un'esperienza utente generalmente migliore. Le pagine non si caricano più velocemente, funzionano meglio e sono più sicure, ma gli utenti possono essere molto più efficienti, consentendo all'azienda di risparmiare tempo e denaro su pagine web lente, arresti anomali casuali, comportamento bizzarro. Quel genere di piccole cose ha un enorme impatto sulla linea di fondo.
DEVELOPMENT OVERHEAD: i nuovi standard sono progettati per rendere più facile / più sicuro per gli sviluppatori la creazione, la manutenzione e l'implementazione di applicazioni. Non solo è più facile e il codice ha più senso, è molto più probabile che uno sviluppatore ottenga informazioni utili o aiuti durante la ricerca o cercando di trovare modi per risolvere l'applicazione in caso di problemi. Il codice più recente consente sia agli sviluppatori che alla gestione di dormire meglio di notte.