Bacheca - Ottimizzazione database

.
22.3. La necessità di capire perché, non è affatto un problema. Solo i bambini seguono ciecamente regole semplici e tu non sei certo uno di loro.
.
23. Confermato:users.total_bulletins è ridondante; può essere derivato. Rimosso.
.
24. Tutti i tuoi PK sono ID. Non ti sei ancora stancato di perderti nel codice? Dimentica di incollare Id iot PKs su tutto ciò che si muove, scopriamo come funzionano i tuoi utenti Identificare le loro entità; quali Entità sono veramente Indipendenti e le altre che dipendono da Entità Indipendenti.

24.1. Non utilizzare mai Id o qualsiasi forma simile. Se si tratta di una PK, utilizzare il modulo completo.

24.2. Chiama location_id, location_id, ovunque si trovi, inclusa la tabella PK. L'eccezione è quando è necessario mostrare il ruolo. Ciò risulterà chiaro nel modello di dati.
.
25. Non hai integrità referenziale dichiarativa, nessun definito Chiavi esterne. Questa è una cattiva notizia per molte ragioni diverse. Una volta chiarite queste domande, aggiungerle. DRI significa che per quanto possibile, se non del tutto, l'integrità viene dichiarata in SQL. Lo standard SQL ISO/IEC/ANSI lo consente, ma la parte del mercato freeware non fornisce lo standard e sta lentamente recuperando terreno. Significa che il server non consentirà l'aggiunta di una riga nella tabella FK a meno che il PK non esista nella tabella padre. MySQL ha recentemente fornito DRI per le chiavi esterne. Per gli FK, fare riferimento a ▶ questo articolo◀ .

25.1. Per i vincoli e le REGOLE CHECK, dovrai implementarli nel codice.

le mie chiavi esterne sono come, users-id(fk) =users.id(pk) Non sono sicuro di come aggiungerle oltre a quello che ho fatto, ma lo farò sicuramente una volta che so come farlo.

Venticinque. Commenti annotati. Non sono uno specialista di MySQL. Sì, questi sono i problemi che devi risolvere da solo. In generale, dalla mia lettura, MySQL è senza gambe; per qualsiasi cosa SQL, hai bisogno di InnoDB.

.
27. Dato:Ho ripensato i requisiti di ordinamento per il bollettino. Gli utenti possono ordinare cronologicamente - facile, ha senso. Gli utenti possono ordinare i bollettini in base alla data dell'ultima risposta al bollettino. Quindi possiamo dimenticare il grado e dovrebbe essere davvero facile ordinare i bollettini cronologicamente al momento della loro ultima risposta? Quali sono i tuoi pensieri.

Problemi aperti

(Nessuno)

Modello di dati

Ok, supponendo che tu non abbia problemi con l'ERD e implementando tutti i problemi chiusi, ho modellato i dati e preparato un Fifth Data Model 09 Dec 10 per la tua revisione. Ho decisamente bisogno di molto di più feedback, domande, ecc. su questo. Ho difficoltà ad accettare che sia fatto. Probabilmente è meglio iniziare a scrivere codice reale per le tue aree problematiche.

Link

▶Link a IDEF1X Notation◀ Devi davvero leggerlo e capirlo, prima di leggere il Data Model.

▶Link ai dati del quinto bollettino Modello◀ Il Diagramma delle relazioni tra entità è nella prima pagina, seguita dal Modello di dati .

• Le chiavi sono praticamente IDEF1X (tranne UserId che ho fornito come contrappunto); che significa borsa Chiavi relazionali. Non ottimizzato e non ottimizzato per considerazioni fisiche. Prima di odiarli, notateli, registrateli e valutateli. Ovviamente possiamo aggiungere Id iot keys, ma prima di farlo, assicuriamoci di capire cosa perderemo.

• Notare gli identificatori (linee continue) come da documento Notation. La colonna vertebrale, le vertebre del sistema è Location ... Bulletin ... Response .

• Nota che le chiavi implementano effettivamente molte regole aziendali.

• Notare la Gerarchia Naturale che ho reso. Vedi se ha un significato per te.

• Le frasi verbali sono davvero importanti; vedi se significano qualcosa.

Commenti sul primo modello di dati e risposte

Una domanda che ho è che la chiave primaria della posizione verrà utilizzata per formare la chiave primaria figlio? (sono uniti da una linea continua) Non capisco davvero questo concetto

• Che cos'è un buon identificatore per Bollettino? , cosa usano naturalmente i tuoi utenti per identificare un bollettino...
• "hai visto il bollettino della Virginia FO ieri?",
• "Sally da Washington scrive sicuramente buoni bollettini", ecc.

o perché tale relazione non esiste tra l'utente e il bollettino?

• Secondo l'intenzione sopra indicata, poiché ora ho mostrato il Rating come una tabella e quale sarebbe il rendering, una volta lo rimuoverò

• Penso che l'autorizzazione dovrebbe essere un'entità.

• Bulletin PK ora è (StateCode, Town, UserId, SequenceNo) . Per essere chiari, SequenceNo è all'interno di StateCode, Town, UserId :saranno le 5 per il 5° bollettino di Sally su MO/Billngs FO.

• Tieni presente che le impostazioni dell'utente BulletinsPerPage ,ecc, sono 1::1 con User , quindi sono in User; la tabella figlio non sarebbe corretta.

• Errori tipografici corretti.

Commenti sul secondo modello di dati e risposte

• I PK per entrambi i Bulletin e Response sono stati modificati per riflettere (7). BulletinNo e ResponseNo sono stati sostituiti con BulletinDate e ResponseDate (che era CreatedDate ), al fine di consentire risposte multiple per User per Bulletin .

Commenti sul terzo modello di dati e risposte

Fidati di aver avuto una buona pausa.

1. Almeno 30 anni fa (di cui sono a conoscenza), i giganti del settore hanno avuto questo dibattito. I nomi sono sempre singolari. Le tabelle sono nomi. Le frasi verbali sono verbi. Questo non si limita alle convenzioni di denominazione dei db, si applica a documenti, tesi, dissertazioni, ecc. Potresti avere 5 conclusioni alla fine del documento, ma il titolo della sezione o del capitolo, sia nel ToC che nella parte superiore della pagina è "Conclusione".

   Dopo averli combattuti per tutta la durata dell'università, non appena ho iniziato il mio primo lavoro di programmazione retribuito, e ho visto l'importanza delle regole nel mondo reale, in contrasto con le argomentazioni teoriche che avevamo all'università, l'ho rinunciato come uno spreco di tempo. Tutto il tempo e l'energia che ho sprecato sono stati liberati per fare un lavoro produttivo. Da allora non metto in discussione i giganti; Accetto e basta. Che le loro menti sono più grandi della mia. È come accettare gli Standard, o comportarsi secondo la legge, o Dio. Non ho davvero, davvero buone ragioni per fare qualcosa di illegale.

   Tuttavia, la facilità di linguaggio (discussione, SQL, documentazione) supportata da tali regole non può essere adeguatamente spiegata; man mano che scrivi sempre più codice SQL, diventerà chiaro.

   Sei sempre libero di usare quello che vuoi. Consegno solo singolare.

2. Bene con me.

   Ma devi tenere a mente che questi due elementi, nella sequenza identificata (ad esempio Indice univoco non PK o Chiave alternativa) sono universalmente richiesti per stabilire l'unicità per una persona. La loro rimozione risulterà in due cose. Innanzitutto, non sarai più in grado di identificare l'unicità tra gli Users (e quindi potresti avere righe duplicate). In secondo luogo, l'AK diventa non univoco, una voce di inversione.

3. Il punto è (contrariamente a uno dei post), qualsiasi colonna che sia 1::1 con User PK, dovrebbe risiedere inUser . Tutte le impostazioni delle preferenze. Dato che abbiamo ripulito le InterestedLocations e InterestedCategories , conosco solo BulletinsPerPage residuo; ma sono sicuro che ce ne sono altri. IsPreference2 è un es. di un booleano;NumPreference3 è un es. di un intero. Ecc. Puoi dirmi quali sono le vere Preferenze.

   (Proviamo al plurale:... qualsiasi colonna che sia 1::1 con Users PK, dovrebbe risiedere in Users . Semplicemente non fa per me, rimango bloccato dall'inglese stentato e sono un po' prezioso per la mia lingua madre.)

   Modello dati aggiornato.

4. Eccellente. Fammi sapere quando ti senti a tuo agio e ti darò il modello fisico.

   Che ne dici delle frasi verbali?

Commenti relativi al 06 dicembre 10 20:38 EST (piccoli aggiornamenti)

.
28. Dove c'è solo un'occorrenza di PK come FK, ovviamente, il nome della colonna FK è lo stesso del nome della colonna PK. Tuttavia, quando c'è più di un occ dell'FK (dai un'occhiata a ResponseRating ), ci sono tre UserIds ), dobbiamo differenziarli. Nella terminologia IDEF1X questo è chiamato Ruoli. Il ruolo dell'User che ha emesso il Bulletin è Issuer , e così via. Ovviamente è meglio usare quel nome e mantenerlo coerente in tutta la gerarchia (non UserIds nel Bulletin e poi quando arriviamo a Response , dove ce ne sono due ed è richiesta una differenziazione, cambialo in IssuerId . Ho pensato che potresti avere un problema con quello; nelle fasi iniziali, l'utilizzo è Issuer.UserId in modo che sia assolutamente chiaro che è UserIds come FK e il ruolo è Issuer; quando arriviamo al modello fisico, viene semplificato in IssuerId .

Allo stesso modo, abbiamo molte colonne DateTime (Date in breve se vuoi; altrimenti Dtm), che devono essere differenziate.
.
29. Il documento di notazione IDEF1X non aveva senso?

• Il PK per ogni tabella è sopra la riga, nell'ordine specificato.
• Ricorda che stiamo comunque trasportando le PK delle tabelle padre e, se c'è un significato, usiamo quelle FK per formare la PK figlio.

• Per Bulletin :

  • La posizione FK (StateCode, Town) per cui è rilasciato
  • Il UserIds dell'Emittente
  • e DateTime è stato rilasciato, per renderlo unico.
  • quindi (Codice Stato, Città, IssuerId, BulletinDate)`

• Per eliminare tutti i ResponseRatings per questo Bulletin , usa WHERE = su quei quattro Bulletin colonne.

.
30. Perché (State, Town) è la PK di Location , portando ovunque. E fa parte del Bulletin PK, quindi tutte le tabelle dipendenti contengono quelle colonne perché contengono il Bulletin PK.

In precedenza avevamo identificato quel (State, Town) è il PK, Lo lascerò così com'è Fare riferimento a (38) per la modifica.

.
33. Vale la pena discutere. Sì, se hai intenzione di visualizzarlo quando (ad es.) visualizzi Responses e gli utenti comprendono UserName . No, se sono 30 byte e c'è anche un UserIds univoco da 4 byte . L'idea è di fare queste scelte consapevolmente, consapevoli di ciò a cui stai rinunciando, quando alla fine decidi che una chiave di 6 colonne da 30 byte è troppo ingombrante per migrare verso i bambini.

• Ho dichiarato all'inizio che avrei usato UserIds come un tipico Id Pk, perché viene trasportato/migrato in diverse tabelle figlio.
• Possiamo lasciare come viene creato per dopo. Ma è un PK surrogato puro.

.
34. Nessun problema. Category ce l'ha già. Cambierò Order a ListOrder .

.
35. Sicuro. Sulla base di ciò che ho letto e sentito, sono abbastanza soddisfatto. Ma vorrei più avanti e indietro per ottenere una certa sicurezza, prima di scrivere il codice. In alternativa, considerala come un'esperienza di apprendimento e accetta che il modello e il codice possano cambiare in seguito. Vuoi che produca il Physical adesso? Se mi date tutte le correzioni, pubblicherò la prossima versione. Mi aspetto le preferenze in User . Inoltre, esegui rapidamente le funzioni e verifica di avere tutte le colonne di cui hai bisogno.

Guarda alcune delle altre risposte, ai fini dell'apprendimento e dell'interesse.

.
36. Si unisce. Ti unisci solo a four tre colonne invece di una. SQL è ingombrante con i join e la nuova sintassi che avrebbe dovuto renderlo più semplice, è in realtà più ingombrante. I miei programmatori non scrivono mai join:risparmiamo tempo e errori di battitura. Ho un processo che, dati due o più tabelle, genererà il codice con tutte le colonne e i join. Non conosco abbastanza MySQL per convertirlo per te.

Modello dati aggiornato.
.

Commenti sull'8 dicembre 10 20:49, quarto modello di dati e risposte

.
Controlla la sezione precedente subito sopra, ci sono piccoli aggiornamenti.

IDEF1X:La tua velocità va bene.

Nota il bambino sempre "eredita" la Parent PK, come una FK (linea continua o tratteggiata), altrimenti non c'è alcuna Relazione tra di loro. Utilizzando queste colonne che esistono comunque nel figlio, per formare il figlio PK, portiamo il significato (e questa è la differenza tra solido e rotto). E quindi non abbiamo bisogno di cercare un identificatore indipendente per il bambino. Il potere relazionale in questo metodo diventerà chiaro in seguito, durante la codifica.

La sezione di cui ci occupiamo riguarda gli Identificatori :naturale vs innaturale; significativo vs insignificante. Più avanti vedrai come possiamo usare la capacità relazionale del motore, quando il PK figlio è formato dal PK genitore. (Il tuo cognome non è uguale a quello di tuo padre?)

È anche importante comprendere i database relazionali e le loro capacità. Ciò si perde quando ci avviciniamo al database (ad esempio) da una prospettiva OO e lo trattiamo come una posizione per rendere le nostre classi "persistenti". Pertanto, cercheremo di imparare e utilizzare i termini relazionali. Diventa difficile quando vai in Francia e ti aspetti che parlino americano e utilizzino la stessa valuta; impara a parlare 10 parole di francese e ti accolgono a braccia aperte e avrai un'esperienza completamente diversa con la gente del posto.

Ad ogni modo, procedi con l'implementazione del modello. Renditi conto che probabilmente faremo un cambiamento ad un certo punto. Salva tutti i tuoi DDL. Salva tutti i tuoi dati di test come istruzioni di inserimento o come backup di una tabella o esportazione in formato carattere (non ho idea di cosa MySQL possa/non possa fare in quest'area)..
37.1. Gestito, il n::n Relazione con Office &Category . Lo "vedrai" solo quando arriveremo al Modello Fisico.

37.2. Fatto.

37.3 Fatto.
.
38. Eccellente. Anche più corto. Nota che non potranno mai avere due Offices nello stesso CAP. NUMERIC(5,0) va bene, ma pensavo che gli Stati Uniti si stessero spostando verso le 7 cifre. Non importa, puoi capirlo; è un eccellente PK per Office . Ora questa colonna, che faceva parte di Address , probabilmente ZipCode , è stato elevato a uno scopo superiore, senza duplicazioni; poiché lo stiamo trasportando in 5 tabelle figlio e vogliamo che il nome PK sia chiaro, come per le convenzioni spiegate in precedenza, lo chiameremo OfficeCode; OfficeZipCode potrebbe essere sciocco.

Abbiamo bisogno di un indice univoco su Name per assicurarsi che non aggiungano due Offices con lo stesso nome. Nota, a scopo esplicativo, questa è in realtà la chiave logica di Office , sostituendo (StateCode, Town) , e così rimane.

Penso ancora che potresti aver bisogno di StateCode e Town come riferimento rapido (diverso dal sedersi da qualche parte in Address )

Data Model aggiornato, quinto ora disponibile per la revisione. Non hai indicato la tua preferenza, per ...Date rispetto a ...Dtm . Sto andando con quest'ultimo, in quanto è più specifico, identificando anche la componente temporale. Facile da cambiare.

Questa risposta ha raggiunto la lunghezza massima. Continua nella "Parte II"