Perché usare MySQL per un sito Web del dizionario è una cattiva idea?

Non posso dirti perché è una cattiva idea. Posso dirti una serie di motivi per cui un database relazionale è comunque un'idea buona .

1. Ricorda che non tutti consultano un dizionario per una definizione. Più volte, un dizionario viene utilizzato per trovare l'ortografia corretta. Ciò significa che non sei solo trovare un ago in un pagliaio , stai cercando il pagliaio per gli aghi che sono simili a quello descritto dall'utente (se posso usare un idioma).

   Non farai solo ricerche di chiavi primarie. Farai ricerche per parole chiave

2. Le parole possono essere correlate, sia nel significato che nell'ortografia ( leggi, leggi , red e reed )

   Ogni volta che vedi la parola "related" pensa "Database relazionale"

3. Se hai bisogno di velocità, hai bisogno di memorizzare nella cache il tuo database relazionale, non un modello di dati relazionale rotto

4. Un database correttamente normalizzato accelera le ricerche e le ricerche di chiavi primarie poiché c'è solo un minor numero di bit da esaminare.

5. Le persone che dicono che i database normalizzati sono più lenti si riferiscono allo 0,1% dei casi in cui ciò è vero. Nell'altro 99,9% dei casi non hanno effettivamente lavorato con un database veramente normalizzato per vedere la performance in prima persona, quindi ignorarli. Ho lavorato con un database normalizzato. Lo adoro. Non voglio tornare indietro. E io non sono un ragazzo di database. Sono un ragazzo C # / JavaScript / HTML / Ruby.

6. Le parole hanno un'origine. In effetti, molte parole nella stessa lingua possono avere la stessa origine, che è un'altra parola in una lingua diversa. Ad esempio, il curriculum (la cosa che carichiamo ai siti web dei reclutatori in modo da poter ricevere incessanti chiamate telefoniche ed e-mail per i prossimi 7 anni) è una parola francese.

7. Un dizionario definisce anche che tipo di parola è (sostantivo, verbo, aggettivo ect). Questo non è solo un testo: "sostantivo" ha anche un significato. Inoltre con un database relazionale puoi dire cose come "dammi tutti i nomi per la lingua inglese" e dal momento che un database normalizzato utilizza chiavi esterne e le chiavi esterne hanno (o dovrebbero avere) indici, la ricerca sarà immediata.

8. Pensa a come vengono pronunciate le parole. Soprattutto in inglese, molte parole hanno la stessa pronuncia (vedi il mio esempio sopra con read e reed, o read e red).

   La pronuncia di una parola è, a sua volta, un'altra parola. Un database relazionale consente di utilizzare chiavi esterne per qualsiasi pronunce. Queste informazioni non saranno duplicate in un database relazionale. Viene duplicato come un matto in un database non SQL.

9. E ora parliamo di versioni plurali e singolari di parole. :) Pensa a "barca" e "barche". O il fatto stesso che una parola è "singolare" o "plurale".

10. Oh! E ora parliamo di tempo passato, tempo presente, tempo futuro e participio presente (per essere onesti, non so quale sia il "participio presente" di merda. Penso che abbia qualcosa a che fare con parole che terminano in "ing" in inglese o qualcosa del genere).

    Cerca "run" e dovresti vedere gli altri tempi: ran, run, running

    In effetti, "tempo" è un'altra relazione stessa.

11. L'inglese non lo fa così tanto, ma il genere è un'altra cosa che definisce una parola. Lingue come lo spagnolo hanno il suffisso che definisce se il soggetto del nome è maschio o femmina. Se hai bisogno di compilare gli spazi vuoti per una frase, il sesso è estremamente importante in molte lingue.

    Poiché non è sempre possibile fare affidamento sulle convenzioni linguistiche per determinare il genere (in spagnolo, le parole che terminano con "o" sono maschili / maschili, ma non è vero per tutte le parole), è necessario un valore identificativo: Maschio o Femmina. Questa è un'altra relazione che un database normalizzato gestisce con garbo anche a milioni di record.

Con tutte le regole e le relazioni intrecciate tra parole e persino linguaggi diversi, è difficile per me immaginare questo archivio dati come un "negozio di documenti" come una soluzione no-SQL. Ci sono così tante e così tante varietà di relazioni tra parole e componenti che un database relazionale è l'unica soluzione sensata.

Se vai con l'archivio dei valori-chiave (che ti offre un modello di programmazione più povero) e risulta che hai bisogno di più struttura (nel tuo caso, per esempio, aggiungendo una terza lingua), o devi fare più complessi le query che coinvolgono i join, passerai un po 'di tempo a riorganizzare le tue chiavi, denormalizzare i tuoi dati e / o a scorrere su tutti i dati per trovare quello che ti serve.

Se inizi con un database relazionale, puoi lavorare sulla progettazione, sul codice e provarlo, concentrandoti maggiormente sul modello di dati naturali per la tua applicazione, piuttosto che su un nuovo modello di valore-chiave.

Una volta che l'applicazione si è stabilizzata, puoi lavorare sulle prestazioni, misurando varie opzioni. Ci sono alcuni trucchi di prestazioni da fare in SQL prima di dover cambiare tecnologia. Avrai imparato molto sulla tua applicazione e sarai in una posizione molto migliore per decidere se la relazionalità ti sta danneggiando e se il valore-chiave funzionerà per il tuo modello dati.

Se risulta che il valore-chiave è esattamente ciò di cui l'applicazione ha bisogno, puoi passare senza sprecare investimenti significativi nel modello relazionale, mentre il contrario potrebbe finire per perdere tempo a fare fare il modello di valore-chiave cose che sono banali nel modello relazionale.

Considera il database relazionale come un acceleratore per rendere la tua applicazione progettata, scritta e attiva e funzionante, di fronte a requisiti in continua evoluzione man mano che impari a conoscere meglio il tuo dominio e gli utenti.

Quando hai milioni di utenti, dovresti quasi sicuramente rifattorizzare il design, anche se avevi scelto il valore-chiave per iniziare.

Per un database così piccolo, probabilmente non farà molta differenza per le prestazioni. Un RDBMS standard non è un'idea terribile qui perché presumibilmente, dovrebbero esserci molte più letture rispetto alle scritture di una determinata voce. Le prestazioni non sembrano essere un driver principale per questo. Il caching nel livello dell'applicazione attenua anche tali preoccupazioni.

L'altra considerazione è la replica e la resilienza. I database relazionali tendono a essere progettati attorno a una singola istanza. Dovresti leggere il teorema CAP e considerare ciò che conta di più per te.

Questi database NoSQL sembrano sempre una buona idea all'inizio, ma ti verrà garantito un problema quando inizi a trattare casi limite (ad esempio, dove le parole chiave devono essere ricercate dal loro valore (o parte di) per esempio.

Sarebbe un'opzione più sicura per andare con un database relazionale all'inizio e poi denormalizzare più tardi. MySQL è fantastico per questo tipo di scopo (semplici database relazionali con ricerca basata su testo), non ci sono troppi casi d'uso in cui troverai difficoltà con questo tipo di dati. Assicurati di aver impostato correttamente gli indici e troverai che si comporterà a un livello comparabile (o meglio quando si esegue una ricerca di testo) a un database NoSQL e ti darà la flessibilità di modificare la logica dell'app senza essere legato a una struttura dati concreta.

Come trovi l'uso più comune dei tuoi dati (e se trovi che non soddisfa le tue esigenze in termini di prestazioni), puoi procedere a de-normalizzare i dati emettendo un formato impostato che può essere caricato in (e recuperato da) uno schema NoSQL.