Si possono avere 2 tabelle con struttura identica in uno schema DB valido?

Question

2 tabelle:
- Visto
- download

una struttura identica:
item_id, user_id, tempo

Dovrei essere preoccupato?

Answer 1

Non penso che ci sia un problema di per sé.

Quando si progetta un DB ci sono molti parametri diversi, e alcuni (ad es .: prestazioni) possono avere la precedenza.

Caso in questione: anche se le strutture (e suppongo che l'indicizzazione) sono identiche, forse le "viste" hanno più record e saranno accessibili più spesso. Questa sola potrebbe essere una buona ragione per non caricarla di record dai download.

Inoltre, il fatto che siano indentici ora non significa che saranno in futuro: viste e download sono diversi, dopotutto, quindi prima o poi uno o entrambi potrebbero coltivare un campo o due in più.

Answer 2

Queste tabelle sono le stesse ADESSO ma potrebbero cambiare lo schema in futuro. Se rappresentano 2 concetti diversi, è bene tenerli separati. Che cosa succede se si desidera avere una chiave esterna da un'altra tabella alla tabella dei download ma non la tabella delle visualizzazioni, se fossero la stessa tabella non è possibile farlo.

Answer 3

Dal punto di vista della modellazione E/R non vedo un problema con questo, purché rappresentino due entità semanticamente diverse.

Da un punto di vista implementativo, in realtà dipende da come si prevede di interrogare i dati:

• Se avete intenzione di interrogare queste tabelle in modo indipendente l'uno dall'altro, tenendoli separati è una buona scelta
• Se avete intenzione di interrogare quei tavoli insieme (magari con un UNION di un'operazione JOIN) si dovrebbe prendere in considerazione la loro memorizzazione in una sola tabella con una colonna discriminatore per distinguere il loro tipo

nel valutare se consolidare loro int oa singola tabella si dovrebbe anche tener conto di altri fattori come:

• La quantità di dati memorizzati in ciascuna tabella
• La velocità alla quale i dati cresce in ciascuna tabella
• Il rapporto tra operazioni di lettura/scrittura eseguita su ogni tabella

Answer 4

Penso che la risposta debba essere "dipende". Come ha sottolineato qualcun altro, è probabile che lo schema di una o di entrambe le tabelle evolva, quindi no. Riesco a pensare bene ad altri casi (semplificando il modello di sicurezza consentendo ad app/utenti l'accesso all'uno o all'altro).

Detto questo, lavoro con un DB legacy in cui questo è un problema. Abbiamo più tabelle identiche per le fatture dei clienti. I dati vengono effettivamente spostati tra loro in fasi diverse del ciclo di vita del processo. Rende un pasticcio complicato quando si tenta di accedere ai dati.Sarebbe stato facilmente risolto da un flag di stato nello schema originale, ma ora abbiamo più di 20 anni di codice scritto contro la versione multi-table.

Risposta breve: dipende dal motivo per cui sono lo stesso schema :).

Answer 5

Chris Date e Dave McGoveran hanno formalizzato lo "Principle of Orthogonal Design". In parole povere vuol dire che nella progettazione del database si dovrebbe evitare la possibilità di consentire la stessa tupla in due diversi relvars. L'obiettivo è quello di evitare determinati tipi di ridondanza e ambiguità che potrebbero risultare.

Probabilmente non è sempre del tutto pratico farlo e non è necessariamente chiaro esattamente quando il principio viene violato. Tuttavia, ritengo che sia una buona regola guida, se non altro perché evita il problema della logica duplicata nel codice di accesso ai dati o nei vincoli, cioè è un buon principio DRY. Evitare di avere tabelle con significati potenzialmente sovrapposti a meno che non ci sia un vincolo di database che impedisce la duplicazione tra di loro.

Answer 6

Dipende dal contesto: cos'è un View e cos'è un Download? Un Download implica un View (in quale altro modo sarebbe scaricato)?

È possibile di avere concetti ben definiti e separati, ma è un odore che vorrei approfondire ulteriormente. Sembra probabile che una vista e un download siano collegati in qualche modo, ma il tuo modello non mostra nulla.

Answer 7

Stai dicendo che entrambe le tabelle hanno una chiave primaria 'item_id'? In questo caso, i campi hanno lo stesso nome, ma non hanno lo stesso significato. Uno è un 'view_id', e l'altro è un 'download_id'. Dovresti rinominare i tuoi campi di conseguenza per evitare questo tipo di incomprensioni.