Come migliorare lo schema del database con diverse associazioni n: me 1: n tra utenti / attività / commenti / allegati

Naviga le tue risposte
0

Sto cercando di creare un database per un prossimo webproject di Ruby on Rails.

Ci saranno 4 tabelle minium: compiti, utenti, allegati e commenti. E 1 tabella per unire le relazioni n: m (attività < - > utenti).

Un'attività ha molti utenti, molti commenti e molti allegati. Un commento ha molti allegati ed è stato creato da un utente. Un allegato è stato creato da un utente.

Gli utenti possono avere molte attività, molti commenti e molti allegati.

Un piccolo schizzo per illustrare i miei pensieri:

Le tabelle con relazioni 1: n contengono l'ID della tabella correlata (ad es. un commento contiene l'id utente)

Pensi che questo schema segua le regole di normalizzazione? Ha senso o ci sono ridondanze? Penso che ci sia un piccolo problema con la tabella degli allegati, perché questo deve contenere un campo tipo e un campo id per distinguere tra attività e commenti.

E tutti i tipi di contenuto (attività, commenti, allegati) sono assegnati da molti utenti (attività) o creati da (commenti, allegati) un utente.

I commenti sono non ricorsivi.

Ho preso in considerazione il seguente pseudocodice: 

tasks = getTasks
each tasks as task

    # get task content

    users = getUsersByTaskID
    each users as user
        #get user content

    attachments = getAttachmentsByTypeAndTaskID
    each attachments as attachment
        # get attachment content
        user = getUserByID

    comments = getCommentsByTaskID
    each comments as comment
        # get comment content
        user = getUserByID
        attachments = getAttachmentsByTypeAndCommentID  
        each attachments as attachment
            # get attachment content
            user = getUserByID

Penso che sia ancora un po 'complicato. Ho trascurato qualcosa? Ci sono modi migliori per implementare le mie idee?

    
posta Slevin 22.01.2013 - 21:44
fonte

2 risposte

2

Penso che il tuo schema sia chiaro:

  1. Non vedo ridondanze

  2. sui tuoi dubbi riguardo la tabella degli allegati: rails rende relativamente facile avere CommentAttachment e TaskAttachment deriva da un comune modello Attachment con ereditarietà di una singola tabella (STI) . STI è praticamente una configurazione di binari standard. Viene fornito ad un certo costo, tuttavia, vedi ad es. questo articolo per alcune discussioni su i contro.
    Ad ogni modo, nel tuo caso, direi che STI è la scelta giusta perché:

    • i 2 tipi di allegati condividono tutti gli attributi.
    • solo il loro comportamento cambia in base al loro tipo.
risposta data 23.01.2013 - 15:00
fonte
1

Modifica: ho riletto i tuoi requisiti e spostato un po 'il mio design.

Vorrei prendere in considerazione l'orientamento dei modelli attorno all'attività, laddove possibile: 

class User; end

class Task
  belongs_to :created_by,    :class_name => "User"
end

class TaskAssignment
  belongs_to :task
  belongs_to :assigned_to,   :class_name => "User"
  belongs_to :created_by,    :class_name => "User"
end

class Comment
  belongs_to :task
  belongs_to :created_by,    :class_name => "User"
end

class Attachment
  belongs_to :created_by,    :class_name => "User"

  # Consider connecting attachments to :comment (and thus indirectly to a parent task) 
  # instead of directly to the :task
  #
  belongs_to :task
end
    
risposta data 23.01.2013 - 14:23
fonte

Leggi altre domande sui tag

Generatore di diagrammi ad albero semplice dipendenza [chiuso] Perché il lavoro di caching di Firefox verrà ripristinato nella versione 3 ma la versione 16 no?