Ho bisogno di usare veramente INNER JOIN?

Naviga le tue risposte
3

Immagina un coiffeur, con i suoi servizi: 

+----+-----------------+--------+
| id |      name       | amount |
+----+-----------------+--------+
|  1 | hair cut        |     40 |
|  2 | shampoo         |     10 |
|  3 | french manicure |     90 |
+----+-----------------+--------+

Immagina una tabella di transazioni: 

+----+------------+------------------+
| id | id_service | date_transaction |
+----+------------+------------------+
|  1 |          1 | 01/01/2015       |
|  2 |          1 | 02/01/2015       |
|  3 |          1 | 02/01/2015       |
|  4 |          2 | 02/01/2015       |
|  5 |          2 | 02/01/2015       |
|  6 |          1 | 06/01/2015       |
|  7 |          1 | 06/01/2015       |
|  8 |          3 | 06/01/2015       |
|  9 |          2 | 06/01/2015       |
| 10 |          2 | 10/01/2015       |
| 11 |          1 | 10/01/2015       |
| 12 |          3 | 10/01/2015       |
| 13 |          1 | 10/01/2015       |
| 14 |          2 | 10/01/2015       |
| 15 |          2 | 11/01/2015       |
| 16 |          1 | 16/01/2015       |
+----+------------+------------------+

Con un semplice INNER JOIN possiamo leggere, ad esempio, la SOMMA di un giorno specifico.

Ma il nostro coiffeur non è una tecnologia addicted e domani cambierà ogni servizio.

Quindi, per evitare questo dramma, come devo impostare la mia webapp?

1) Ripeto service.name e amount.name ogni volta nella tabella delle transazioni? Quindi, io non uso l'INNER JOIN?

1a) Potrei perdere anche la possibilità di GROUP BY, senza ID numerico. E non posso usarli dalla tabella dei servizi perché la modifica del servizio (o, peggio) viene cancellata ...

2) Devo bloccare l'utente per modificare / cancellare i suoi servizi?

3) Quale considerazione?

    
posta sineverba 22.01.2015 - 16:37
fonte

3 risposte

6

La domanda non dovrebbe essere se hai bisogno o meno di usare inner joins.

Il design è difettoso. Il difetto è che all'entità della transazione manca una proprietà, cioè la tabella delle transazioni manca di una colonna per registrare la quantità dell'operazione. L'altro difetto è che la "quantità" di un servizio è davvero il suo "prezzo".

  • Aggiungi una colonna amount alla tabella transaction .
  • Rinomina la colonna amount nella tabella service in price .
  • Quando viene aggiunta una transazione, l'importo viene impostato sul valore del prezzo corrispondente.
  • L'utente dovrebbe essere autorizzato a modificare il prezzo di qualsiasi servizio in qualsiasi momento
  • L'utente dovrebbe essere autorizzato a cambiare il nome di un servizio solo se non ha transazioni.
  • Gli usi dovrebbero essere autorizzati a eliminare un servizio solo se non ha transazioni.
  • Le variazioni dei prezzi dei servizi non influiscono sull'ammontare delle vecchie transazioni.
risposta data 22.01.2015 - 17:42
fonte
2

Se vuoi assicurarti che ci sia un elenco stabilito di servizi (una tabella per il join interno), devi gestire la modifica di questa tabella senza interrompere i tuoi join per i record storici.

  1. Usa un soft-delete. Aggiungi un campo all'elenco di servizi chiamato: IsDeleted. Controllalo quando non offri più il servizio. L'ID rimarrà. Probabilmente farei di questo un campo data per sapere quando l'eliminazione è avvenuta a scopo di archiviazione.
  2. Utilizzare un campo data di inizio e un campo data di fine nella tabella dei servizi per indicare quando questi servizi sono stati offerti. Questi campi potrebbero anche essere pubblicati in caso di cambiamenti di prezzo noti in futuro.

Tutto ciò richiederà più codice per gestire la logica di quali servizi sono disponibili quando.

    
risposta data 23.01.2015 - 00:11
fonte
0

La tabella delle transazioni non deve fare affidamento sulla tabella dei servizi. Questo perché nel momento in cui viene eseguita una transazione, la relazione con la tabella dei servizi viene persa. Perché? Apparentemente nella tabella dei servizi il nome del servizio o l'importo del servizio possono cambiare. In una tabella di transazioni storiche, il nome e l'importo saranno quelli che sono al momento in cui vengono inseriti nella tabella delle transazioni e non cambieranno se sono presenti modifiche nella tabella dei servizi.

Ecco perché l'importo non dovrebbe essere nella tabella dei servizi, ma dovrebbe avere la propria tabella. In questo modo puoi mantenere un record di prezzo storico. E no, non fai riferimenti a questo nella tua tabella delle transazioni. Perché un prezzo può essere qualsiasi cosa. (come diciamo che tu entri, ma perché porti anche tuo figlio, il bambino ottiene un taglio di capelli a metà prezzo. La tabella delle transazioni deve avere la libertà di ricevere qualsiasi importo personalizzato.)

Ovviamente puoi mantenere un riferimento alla tabella dei tuoi servizi, quindi se il tuo cliente decide di cambiare "super haircut" in "haircut" che è lo stesso servizio con un altro nome, in questo modo puoi ancora raggruppare.

    
risposta data 23.01.2015 - 14:22
fonte

Leggi altre domande sui tag

È possibile compilare ogni lingua? E ogni lingua può essere interpretata? [duplicare] I compilatori associano il Garbage Collector all'eseguibile finale?