Quando gli sviluppatori hanno iniziato a creare database relazionali normalizzati?

7

Lavoro su una vecchia applicazione che è stata convertita da DOS e file flat per l'archiviazione delle informazioni in tabelle Paradox usando il database BDE e MySQL.

Gli sviluppatori più anziani dicono che la ragione per cui non hanno idea di come creare correttamente una tabella in 3nf è perché il loro codice precede i database relazionali e non li hanno mai appresi a scuola.

Quindi, all'interno di programmi reali, quando ha fatto la maggioranza dei programmatori ad adottare un metodo decente per creare tabelle nei loro database? Se si osservano i database in CMS open source, tali tabelle sembrano ben normalizzate: quelle di successo vengono avviate in quel modo o vengono normalizzate nel tempo (o denormalizzate per motivi pragmatici)?

    
posta Peter Turner 18.07.2011 - 20:48
fonte

8 risposte

17

Il modello relazionale è stato formulato per la prima volta da E.F. Codd nel 1969 e inizialmente è stato implementato in vari database IBM negli anni '70. Mi sembra anche che la prima edizione del seminale di C. J. Date "An Introduction to Database Systems" sia stata pubblicata intorno al 1974.

Ho sentito parlare di database relazionali negli anni '80, senza nemmeno prestare molta attenzione. Oracle, Ingres e Informix trasmettevano tutti database relazionali commerciali orientati ai server nei primi anni '80 e facevano molto bene.

Per quanto riguarda i database relazionali ampiamente utilizzati sui microcomputer, beh ... questa è un'altra questione. I più popolari database di microcomputer degli anni '80 erano decisamente non relazionali - questo includeva dBase, FoxPro, FileMaker e Paradox.

Direi che la transizione verso i database relazionali sui microcomputer si è generalmente verificata durante gli anni '90, quando la capacità di connettersi a database relazionali ospitati su server è diventata comune. Certamente per me - all'inizio del decennio, guardavo piuttosto in modo assente alle persone che menzionavano i database relazionali e, alla fine del decennio, ero frustrato dal dover lavorare con FileMaker (al contrario di Informix, Oracle, o MS Access) perché non era sufficientemente relazionale e non supportava SQL.

    
risposta data 18.07.2011 - 21:25
fonte
3

Come altri hanno sottolineato, la teoria dei database relazionali incluse le forme normali di base è stata sviluppata negli anni '70. Negli anni '80, database relazionali come DB2 e Oracle erano diffusi su mainframe. I primi database per PC come dBase non erano relazionali, e potevo capire i programmatori di PC che avevano tagliato i loro denti su dBase nel 1984 senza conoscere le varie forme normali, ma database relazionali come Sybase e MicroRIM erano disponibili su PC alla fine degli anni '80 e alla fine degli anni '90 i database relazionali avevano praticamente affollato i tradizionali prodotti dBase ad eccezione delle applicazioni legacy. Certamente dal 1993 qualsiasi classe di livello universitario decente sui database avrebbe coperto in dettaglio le forme normali.

    
risposta data 18.07.2011 - 21:48
fonte
2

Bene ... almeno dagli anni '80. Ho avuto la mia formazione presso una nota azienda di software nei Paesi Bassi e fino a quel momento ci avevano insegnato tutti sulla normalizzazione dei dati. La normalizzazione probabilmente si è verificata intorno ai database relazionali, che hanno avuto origine nei primi anni '70.

    
risposta data 18.07.2011 - 21:00
fonte
2

Citato da Wikipedia :

Edgar F. Codd, the inventor of the relational model, introduced the concept of normalization and what we now know as the First Normal Form (1NF) in 1970. Codd went on to define the Second Normal Form (2NF) and Third Normal Form (3NF) in 1971, and Codd and Raymond F. Boyce defined the Boyce-Codd Normal Form (BCNF) in 1974. Higher normal forms were defined by other theorists in subsequent years, the most recent being the Sixth Normal Form (6NF) introduced by Chris Date, Hugh Darwen, and Nikos Lorentzos in 2002.

Per quanto riguarda la decenza del metodo utilizzato per creare database, normalizzati o meno, molte persone direbbero che finché funziona e si comporta con una velocità e accuratezza soddisfacenti, è una soluzione decente. La manutenzione è il vero punto e, come fai notare, a volte è meglio normalizzare, a volte è meglio denormalizzare.

Scott Ambler ha scritto un buon libro sulla manutenzione del database: Tecniche di database agile: strategie efficaci per lo sviluppatore software agile . È possibile refactoring dei database e migliorarli, non così facilmente come il codice, ma ci sono modi.

    
risposta data 18.07.2011 - 21:02
fonte
2

I database relazionali sono in circolazione da un po 'di tempo e la normalizzazione, sebbene piacevole per semplificare il tuo modello di dati, è davvero VERAMENTE piacevole per conservare spazio su disco. Non ho mai usato un sistema che non fosse almeno 1NF, e lavoro su un sacco di schifezze precedenti al 1980.

Diavolo, i moduli normali standard erano per lo più ambientati negli anni '70 ... Alcuni di loro erano ambientati giù prima del 1974, che era l'anno in cui IBM ha rilasciato la prima specifica SQL, e in giro quando è stato rilasciato RDMS.

Quindi sì, la normalizzazione è stata lì fin dall'inizio.

    
risposta data 18.07.2011 - 21:30
fonte
1

La terza forma normale esiste da un po '. Non sono sicuro che tu possa davvero mettere una data su quando gli sviluppatori improvvisamente ha ottenuto la religione. I progettisti di database avrebbero dovuto incorporare la progettazione relazionale nei loro prodotti prima di allora, e ora la "nuova religione" dei database NoSql trasforma l'intera nozione di design relazionale all'orecchio.

È meglio avere un buon design del database dall'inizio. La modifica della struttura del database dopo che l'applicazione ha raggiunto una dimensione non banale è difficile; devi scrivere programmi che traducono dallo schema del vecchio database a quello nuovo, e ciò richiede tempo e risorse per evitare sforzi di miglioramento delle applicazioni.

Quindi direi che i progetti di maggior successo sono quelli in cui la progettazione del database è ben ponderata prima che lo sforzo di sviluppo sia iniziato sul serio.

    
risposta data 18.07.2011 - 20:58
fonte
1

Gran parte di esso dipende anche da DOVE provengono.

Prendimi per un esempio. Ho iniziato a svilupparmi verso la fine degli anni '80 e nella mia parte del mondo (Malesia), gli RDBM non hanno iniziato a fare il giro fino ai primi anni '90.

La maggior parte delle riviste che potevi ordinare erano legate all'hardware e la selezione dei libri era deprimente, per usare un eufemismo. Internet non era neanche lontanamente vicino a quello che è adesso e cercare di ottenere informazioni sempre affidabili per quanto riguarda i prodotti e le innovazioni era impossibile. Tutto ciò ha contribuito a rendere difficile l'autoapprendimento quando si tratta di nuove tecnologie.

L'altra strada per l'apprendimento è stata attraverso le università locali, ma questo non ha funzionato bene in quanto i college nella maggior parte dei paesi del 2 ° e 3 ° mondo non introdurranno nuovi concetti nei corsi di laurea fino a quando non saranno "provati".

Alcuni di noi si sono normalizzati perché avevano un senso. Alcuni di noi sono normalizzati da "incidente". Alcuni di noi che si sono ritirati presto non sanno ancora cosa significhi normalizzazione: P

In ogni caso, se dovessi dargli un appuntamento, direi che la metà degli anni '90 era quando tutti saltavano sul carrozzone "normalizza o muori" nella mia parte del mondo.

A proposito, nessuno dovrebbe pensarla male a prescindere da quando (se mai) hanno acquisito la normalizzazione perché allora era davvero un mondo diverso.

    
risposta data 19.07.2011 - 08:34
fonte
0

Non ho idea di quando la loro università abbia iniziato a offrire corsi in db relazionali o ne abbia fatto un requisito. Sulla base degli altri repspones (1969-1970), rdbms è precedente a DOS (1981), quindi come hanno potuto apprenderlo?

Devi determinare dove la normalizzazione del tuo database andrà a beneficio della tua applicazione. Una volta che vedono alcuni esempi in un database e in un'applicazione con cui hanno molta familiarità, dovrebbero essere in grado di raccoglierlo.

    
risposta data 18.07.2011 - 21:40
fonte

Leggi altre domande sui tag