Printable View
:cool: I was pondering the same thing... :cool:Quote:
Originally posted by Grizzly
And wow - how is it we we're all born at around the same time? Was there something in the planetary alignment during that time that made us all endlessly interested in technical architecture? Maybe we'll never know...
I liked the idea of 'span of time' after looking over all of these models a little more, and after some thought it does seem like a start_date and end_date would allow for the most flexible scheduling. You can still create a single appointment by setting the start and finish date of the schedule to the same day, and one entry in appointments (and of course schedules_appintments too).Quote:
Originally posted by Grizzly
Nice suggestion Tekime. That is actually an approach I toyed around with in my mind when I originally read this thread. It would make sense to me, that any given merchancdiser won't change their schedule from week to week too often. That being the case, one might be able to reduce the amount of data entry by laying out a week or so, and saying "this applies to the next 6 months."
As you mentioned, this is going to depend on the client's needs and whether the merchandisers even follow any kind of schedule. If their schedule randomly changes on a weekly basis, high record count might be inevitable.
Yeah, the shifts table could probably stand for some serious improvement. I pictured it as containing a select number of records, say 'Morning', 'Afternoon', 'Evening', etc. and be used as a lookup table. Or, perhaps a list would be a better solution if that were to be used. If there were restrictions to the shifts each account accepted stocking, your solution A might be a better idea.Quote:
I think you have a great design there actually. The only thing I think could be done better, is the tbl_Shifts relationship. In that model, you can either: A) Allow "Stores" to share a general pool of "shifts" on which they can accept delivery, or B) Force "Stores" to re-enter their "shifts" for every "Schedule" entered.
We'll see how you progressed today Nephalim, let us know how things unfold :)
Something spooky is definitely is going on. I wonder if there is such a thing is technology astrology - determining people's technological inclinations based on astrological indications :cool: Well, Oracle released their first RDBMS in 1979 (or Relational Software as they were known as then). Maybe we're all destined to end up working for them :DQuote:
And wow - how is it we we're all born at around the same time? Was there something in the planetary alignment during that time that made us all endlessly interested in technical architecture? Maybe we'll never know...
ROFL - I thought something about astrology might spill over from Fury-Tech! :pQuote:
Originally posted by Tekime
Something spooky is definitely is going on. I wonder if there is such a thing is technology astrology - determining people's technological inclinations based on astrological indications :cool: Well, Oracle released their first RDBMS in 1979 (or Relational Software as they were known as then). Maybe we're all destined to end up working for them :D
As for my results, from what i can tell so far, the model derived from Grizzly's notes works very well AND will likely only produce about 10K records a year. I also like Tekime's design because it really cuts down on record count by A LOT, but I have to agree that the allowable alotment for project expansion is limited. I think I've chosen my final design, but I'm still looking over all the choices...
Hahaha, the Fury is everywhere, muahahahaha :pQuote:
Originally posted by Nephalim
ROFL - I thought something about astrology might spill over from Fury-Tech! :p
Awesome, glad you have something that looks to be working for you. If you only schedule about 10,000 appointments per year then the model you were going with is probably spot on. Best of luck :)Quote:
As for my results, from what i can tell so far, the model derived from Grizzly's notes works very well AND will likely only produce about 10K records a year. I also like Tekime's design because it really cuts down on record count by A LOT, but I have to agree that the allowable alotment for project expansion is limited. I think I've chosen my final design, but I'm still looking over all the choices...