2009-03-27 18 views
5

Sono interessato a vedere suggerimenti per una progettazione di database per quanto riguarda gli orari di lavoro.Progettazione database: il modo migliore per mostrare le ore disponibili?

Sarebbe del tutto simile a quello che Facebook ha - alt text http://uploader.ws/upload/200903/widget.png

Ho un elenco delle imprese, e vorrei che gli utenti siano in grado di ingresso più insiemi di ore disponibili per tale attività. ad es.

lunedì: aperto 9-5; Martedì: aperto 9-12; 1-5; ecc. Non vorrei essere limitato a due serie di ore al giorno. Idealmente, N serie di ore al giorno. Se questo non è pratico, non più di 4 ... non meno di 2.

Sono interessato alle soluzioni "migliori" (teoriche) e più pratiche.

Il DBMS che sto utilizzando è MySQL.

risposta

6

ne dite:

create table business (
    id int not null auto_increment primary key, 
    name varchar(255) 
); 

create table open_hour_range (
    id int not null auto_increment primary key, 
    business_id int, 
    day_of_week tinyint, /* 0-6 */ 
    open_time time, 
    close_time time, 
    foreign key(business_id) references business(id) 
); 

Questo permette qualsiasi combinazione di ore, tra cui più al giorno. Tuttavia, potrebbe essere un po 'lento dal punto di vista delle query, in quanto dovrai fare un buon numero di iscrizioni per trovare l'elenco delle ore di apertura di un'azienda.

Inoltre, se si vuole essere in grado di visualizzare ore in un formato simile:

MF 9-5 Sa-Do 9-12

Avresti bisogno di unire le gamme simili in codice, fuori dal database. Se si desidera unire questo ordinamento, è possibile modificare day_of_week a start_day e a end_day.

+1

Questo è simile a quello che stavo per postare. Tuttavia, non prenderei in considerazione l'aggiunta di un problema ... Vorrei fare un'unica query separata per selezionare tutti gli intervalli di ore applicabili per un'azienda e lasciare che il codice dell'app gestisca la formattazione. Puoi sempre memorizzare anche l'output nella cache. – zombat

+0

Qual è il vantaggio della colonna open_hour_range.id? –

+0

La colonna open_hour_range.id fornisce un modo per identificare in modo univoco un particolare open_hour_range per l'aggiornamento/la cancellazione. Questa potrebbe essere una cattiva abitudine, immagino che potresti rendere il set completo di colonne del tavolo come chiave primaria. –

0

Con Microsoft SQL Server banca dati è possibile memorizzare i dati come digitato XML ed essere ancora in grado di ordinare i dati e serach sulla base di uno o più valori in quel campo. Fare calcoli, se necessario, ecc

un valore in quella colonna potrebbe essere simile a questo:

<businessDays> 
    <monday> 
     <hours from="12" to="15" /> 
     <hours from="16" to="21" /> 
    </monday> 
    <friday> 
     <hours from="13" to="15" /> 
     <hours from="16" to="18" /> 
     <hours from="19" to="21" /> 
    </friday> 
</businessDays> 

Riferimenti XML digitato:

Riferimenti indicizzazione e XML quering dati in SQL Server:

Nella tua applicazione si potrebbe serializzare/deserializzare questi dati in e da oggetti di business.

Estremamente semplice ed efficiente.

+0

Perché sarebbe un vantaggio? –

+0

Solo 1 colonna viene utilizzata per la memorizzazione di questi dati non strutturati. Nell'applicazione è possibile deserializzare nell'entità aziendale utilizzando le funzionalità di serializzazione/deserializzazione esistenti di .NET. Se dividi quei dati in più colonne o anche tabelle come suggeriscono altri ragazzi -> il risultato è "sovra-standardizzato" –

+0

Spiacente, ho taggato la domanda come MySQL ma non l'ho specificato come requisito nella domanda. Aggiornamento della domanda. – andyhky

3

un tweak minore al modello di Scotty Allen:

tabella di affari:
id - int
BUSINESS_NAME - stringa
open_hour_range tavolo:
id - int
business_id - int // chiave esterna per le imprese
days_of_week- int // (bitmask) 1-127
open_time - tempo
close_time - tempo

+0

Ooh, mi piace l'idea della maschera di bit - intelligente :) –

0

I wolud piuttosto usare datetime nelle colonne open_time e close_time. È per riunioni che inizieranno di notte e termineranno la mattina del giorno successivo. :)

Problemi correlati