Ik probeer momenteel de beste manier uit te werken om een bedrijfsuren in een database op te slaan.
Bijvoorbeeld:
BUSINESS A HEEFT DE VOLGENDE UREN VAN WERKING
- maandag: 9.00 – 17.00 uur
- dinsdag: 9.00 – 17.00 uur
- woensdag: 9.00 – 17.00 uur
- Donderdag: 9.00 – 17:00
- Vrijdag: 9.00 – 17:00
- zaterdag: 9.00 – 12 middag
- zondag: gesloten
Momenteel heb ik een gegevensmodel vergelijkbaar met het volgende
CREATE TABLE "business_hours" (
"id" integer NOT NULL PRIMARY KEY,
"day" varchar(16) NOT NULL,
"open_time" time,
"close_time" time
)
Waar de “Day” is beperkt tot een keuze uit de 7 dagen van de week in de code (via het ORM). Testen als een bedrijf op een bepaalde dag wordt gesloten, controleert het of de Open_Time en Close_Time NULL is. Het is gerelateerd aan het bedrijf via een tussendtafel (velen tot veel relaties).
Heeft iemand suggesties voor dit database-schema? Iets aan het lijkt mij niet goed.
Antwoord 1, Autoriteit 100%
Over het algemeen zie ik hier niets mis mee. Behalve …
-
Ik zou de dag van de week opslaan als een geheel getal met welk nummer van het nummer uw inheemse programmeringstaal gebruikt (in haar bibliotheken). Dit zal de grootte van de database verlagen en stringvergelijkingen uit uw code verwijderen.
-
Ik zou waarschijnlijk de buitenlandse sleutel aan de tabel hier in deze tabel plaatsen. Op die manier hebt u geen linktabel nodig.
Dus ik denk dat ik het zou doen:
CREATE TABLE "business_hours" (
"id" integer NOT NULL PRIMARY KEY,
"business_id" integer NOT NULL FOREIGN KEY REFERENCES "businesses",
"day" integer NOT NULL,
"open_time" time,
"close_time" time
)
In mijn bedrijfslogica zou ik een beperking handhaven die elke “bedrijf” ten minste 7 “kantooruren” heeft. (Ten minste omdat JON SKEET goed heeft, misschien wilt u een vakantie-uren.) Hoewel u deze beperking misschien wilt ontspannen door simpelweg “zakelijke uren” te verlaten voor dagen dat het bedrijf gesloten is.
Antwoord 2, Autoriteit 48%
Eén situatie die niet onder dit schema wordt gedekt, is verschillende openingsperioden op een dag. De lokale pub is bijvoorbeeld open 12: 00-14: 30 en 17: 00-23: 00.
Misschien staat een theaterbox-kantoor open voor een matinee en een avondprestatie.
Op dat moment moet u beslissen of u meerdere inzendingen voor dezelfde dag kunt hebben, of als u verschillende uren in dezelfde rij moet weergeven.
Hoe zit het met openingstijden die middernacht kruisen. Zeg dat een bar geopend is 19: 00-02: 00. Je kon de opening en sluitingstijden niet zomaar vergelijken met de tijd die je wilt testen.
Antwoord 3, Autoriteit 25%
Ik heb geleerd dat als u Google-gegevensmarkering wilt hebben dat u uw gegevens wilt herkennen, moet u deze richtlijnen volgen:
https://schema.org/Osteninghours
http://schema.org/OpeninghoursSpecificatie bevat “Geldige data”, wat erg handig is voor sommige bedrijven.
https://schema.org/docs/search_results.html#Q=Hours
U zou in orde moeten zijn zonder een primaire sleutel, tenzij u bedrijven in staat bent om dezelfde uren te delen met de toetringenlijst – interessant is dat u uiteindelijk een eindige hoeveelheid combinaties zou hebben; Ik weet niet zeker hoeveel dat zou zijn: p
Met een van mijn projecten gebruikte ik de kolommen:
[uint] business_id, [utinyint] dag, [char (11)] Timerange
Als u OpeninghoursSpecification wilt ondersteunen, moet u valideren en valdedrough.
Tijdbereik is geformatteerd zoals: HH: mm-HH: mm
Hier is een functie die het parseert,
U kunt deze functie ook aanpassen om slechts één open / sluiting te ontleden, als u ze als afzonderlijke kolommen in de DB bewaart.
Uit mijn ervaring zou ik aanraden dat je meerdere keren binnen een dag toestaat, een manier toestaat om te vertellen of ze expliciet op die dag worden gesloten of 24 uur of 24/7 geopend.
Ik had de mijne laten zeggen dat als er een dag ontbrak in de DB, de zaak die dag gesloten was.
/**
* parseTimeRange
* parses a time range in the form of
* '08:55-22:00'
* @param $timeRange 'hh:mm-hh:mm' '08:55-22:00'
* @return mixed ['hourStart'=>, 'minuteStart'=>, 'hourEnd'=>, 'minuteEnd'=>]
*/
function parseTimeRange($timeRange)
{
// no validating just parsing
preg_match('/(?P<hourStart>\d{1,2}):(?P<minuteStart>\d{2})-(?P<hourEnd>\d{1,2}):(?P<minuteEnd>\d{2})/', $timeRange, $matches);
return $matches;
}
Antwoord 4, autoriteit 22%
Het hangt er een beetje van af waarvoor je het moet bewaren en hoe de echte gegevens eruit kunnen zien.
Als u moet kunnen bepalen of het bedrijf op een bepaald moment open is, kan het een beetje onhandig zijn om het schema op te vragen zoals uiteengezet. Belangrijker is echter: zou u ooit een middagsluiting moeten regelen?
Sommige opties omvatten;
- Een schema zoals u heeft, maar met de mogelijkheid om meerdere perioden op dezelfde dag te hebben. Het zou geschikt zijn voor de lunchpauze, maar zou het lastig maken om een zoekopdracht uit te voeren die u de openingstijden voor een bepaalde dag geeft, bijvoorbeeld voor presentatie aan een gebruiker.
- Een benadering in bitmapstijl; “000000000111111110000000” voor 9-5. Het nadeel van deze aanpak is dat je een specifieke granulariteit moet kiezen, d.w.z. hele uren of halve uren of zelfs minuten. Hoe fijner de granulariteit, hoe moeilijker de gegevens voor een mens te lezen zijn. Je zou bitsgewijze operatoren kunnen gebruiken om deze waarde op te slaan als een enkel getal in plaats van een reeks gehele getallen, maar nogmaals, het doet afbreuk aan de leesbaarheid.
Antwoord 5, autoriteit 3%
De meeste resultaten werken prima voor het gegeven scenario, maar het zal niet zo effectief zijn als u perioden heeft die meerdere dagen duren, bijv. 8:00 ~ 02:00 uur, dan raad ik aan om een ontwerp met meerdere perioden te gebruiken.
{
id: 1,
day: 1,
periods: [
0: { open: 08:00, close: 00:00 }
]
},
{
id: 2,
day: 2,
periods: [
0: { open: 08:00, close: 00:00 }
1: { open: 00:00, close: 02:00 }
]
}
dag: aantal dagen van de week
als er geen menstruatie is, betekent dit dat het gesloten is
Antwoord 6
Misschien kunt u overwegen om rekening te houden met feestdagen door extra velden op te nemen voor de maand van het jaar/dag van de maand/week van de maand. Week van de maand heeft wat kleine subtiliteiten. “laatste” kan bijvoorbeeld week 4 of 5 zijn, afhankelijk van het jaar.