On 4/7/08, sqlfan <[EMAIL PROTECTED]> wrote: > > I guess I fit in the more ambitious category then. I hope my workload will > increase at any rate. > > Anyway I've looked at some tutorials, but I'm a bit daunted. > > What do you think about this layout: > > [integer booking # (=unique ID)] - [integer start date] - [integer end date] > - [text everything else about the booking] > 1 - > 2 - > 3 - > 4 - > 5 - > 6 - > 7 - > [...] > > then it seems I can "derive" the other "views", such as a view that is by > date > 2008-04-06 [free] [free] [Joe for conference] [free] [free] > Is that right? > > Do I need any other tables other than the one above that I derive the other > views from? > > Thank you!
Did you see the most incredibly detailed and helpful reply that Dennis Cote provided? You owe him a beer (or a free ticket to one of your bookings). He has done most of the work you want. You can take that as the db structure and run with it. Good luck. > > > > > P Kishor-3 wrote: > > > > On 4/7/08, sqlfan <[EMAIL PROTECTED]> wrote: > >> > >> I'm booking five resources, and right now I just use an excel sheet with > >> all > >> the dates in the first column (1/1/2000, 2/1/2000 ..., and the next five > >> columns are the five resources. When I book one, I just scroll to the > >> appropriate date and change the color of the column for that resource > >> for > >> all the dates it's booked for, and then I put any information about the > >> booking (who booked it, their e-mail address if it's someone I don't > >> know, > >> whether it has been paid) somewhere in the colored area. > >> > >> I'd like to start using a database instead, but I'm very very new and I > >> don't know how I should structure it. I think if I do it correctly I > >> think > >> I could check much more easily whether anything is available for a date > >> range, without having to scroll through my excel sheet to find that date > >> and > >> look, which is a pain because it's kind of long. It seems most > >> databases > >> are much more complicated than mine though -- for example, I don't even > >> have > >> any structure to the "extra" information I put about a booking, I > >> sometimes > >> just put a name like "Joe for conference".... > >> > >> How should the database structure look. Am I even doing the right thing > >> by > >> wanting to use a database? I'm very very new and kind of lost, any help > >> would be appreciated. Thank you!! > >> > > > > HI sqlfan, > > > > You may benefit from a database, but for something as simple as what > > you are wanting to do, you might simply get more done by using a > > simpler, readymade program. I work on a Mac, so I don't know about > > other programs, but there a countless "journals" and "diaries" type of > > programs that exist on the Mac. Check out macupdate.com and search for > > keywords like "journal" or "personal information manager." > > > > On the Mac, most of these programs actually utilize SQLite as their > > datastore, but for the user, for you, the interface is really easy, > > readymade, attractive... best of all, most of these programs are very > > inexpensive once you decide to buy one of them... $20 to $40 for a > > license. You will support shareware, you will get your work done, and > > you will be using SQLite without even realizing it. > > > > On the other hand, if your future needs are very ambitious, and you > > are determined to roll your own db-based solution, I suggest you > > search for free SQL tutorials on the web... there are countless. Once > > you go through them, you will be better equipped to decide if you want > > to build your own. At that time you can use this SQLite list to ask > > SQLite-specific questions. > > > > Good luck, but I do recommend a readymade solution for the sake of > > getting work done. > > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
