Semantica di nominare un timestamp MYSQL colonna

Question

Ho bisogno di un tavolo di MySQL che rappresenta questi dati:

• 12 febbraio, 05:00 - Verdasco VS Monfils
• 12 febbraio, 21:25 - Sampras VS Hewitt
• 13 febbraio, 08:15 - Nishikori VS Del Potro

I volevo nominare la colonna temporale tempo, timestamp o data, ma come sai, quelle sono tutte parole chiave riservate. Qual è il modo migliore per nominare una colonna temporale senza un formaggio di proposito per aggirare i limiti di denominazione?

Answer 1

Che cos'è Verdasco VS Monfils? Sono eventi? Quindi andrei con EventDate o qualcosa di simile. Prova a nominarlo come lo descriveresti.

Answer 2

Il nome della colonna non deve puntare al tipo di dati ma al suo significato. Come event_start_datetime o created per il timestamp di creazione di quella voce.

Answer 3

Preferisco verbo al passato e "Time", cioè "createdTime", "publishedTime", nel tuo caso non riesco a trovare un verbo, ma "matchTime" sembra ok.

Answer 4

Capisco la sensazione che una colonna chiamata EventDate in una tabella chiamata Events (che, tra tutte le convenzioni DB che io abbia mai imparato, dovrebbe essere chiamato Evento ...;)) è ridondante, ma prendere in considerazione:

si dispone di un tavolo Event con una colonna Date e un tavolo Booking, il cui record rappresentano un cliente di prenotare un posto ad un evento, anche con una colonna Date (che, in questo contesto, fa riferimento alla data che la sede è stato prenotato):

SELECT e.Date AS EventDate, b.Date AS BookingDate, [...] 
FROM Event e 
JOIN Booking b ON b.EventId = e.Id 

dover rendere conto per i nomi di colonna ambigui in ogni tale interrogazione è una pena che può (e fa, a mio parere) superare la presunta ridondanza dei Event.EventDate.

Consideriamo un altro argomento che possiamo applicare ai nomi delle colonne ID in ogni tabella: chiamando il PK in EventEventId invece di limitarsi a Id ci permette di scrivere questo ENTRA criterio:

JOIN Booking b ON b.EventId = e.EventId 

cui possiamo vedere a colpo d'occhio fa riferimento alle colonne corrette.

In sintesi, se dobbiamo prendere la decisione tra chiamare la colonna Date o EventDate, quest'ultimo ha molti vantaggi:

• Come @Benjamin Seiller sottolinea, una colonna dovrebbe identificare significato della colonna, non necessariamente il suo tipo di dati
• Inoltre, cosa succede quando si dispone di una tabella con tre campi di date differenti che rappresentano le date rilevanti per l'entità? Se non li si fa un nome in base al loro significato , adesso si deve ricordare quale campo significa ciò ...
• Non appena vogliamo interrogare più tabelle, i nomi di colonna ambigui problemi presenti
• Se le colonne che appaiono in più tabelle (come chiavi esterne) hanno nomi espliciti e identici, la nostra sintassi di query diventa un po 'più resistente agli insetti (come l'adesione sulla colonna sbagliata)

prendere in considerazione tutte le situazioni in cui il vostro tavolo può essere usato al momento di decidere i nomi delle colonne. In questo caso, sosterrò che i vantaggi di fornire informazioni specifiche del contesto nel nome della colonna superano di gran lunga la ridondanza della ripetizione del nome della tabella.