Database structuring

[dojobin]

Hi all,

I'm halfway through writing an application that acts as a calendar for appointments (it has other features, so I couldn't just use some appointment book software). The app needs to track past and future appointments. So for example a user might book in for the 14/02/05 at 8:00am and I need to store this in the database so I can pull it up and display the associated info whenever that date is selected from my little calendar control.

What I plan to do is to create 1 table that I just keep appending records to - which might be a bit inefficient once a lot of records have been added. I cannot think of another way to do it, so at the moment, this is what I'll do. I think that the efficiency of this would be pretty much comparable to a flat text file! Can anyone think of a better way of handling this? Surely apps like Outlook, iCal and other calendar apps do this in a more efficient way.

Another idea I tossed up was to have separate tables for each year which would reduce the amount of records I had to search, but that would mean creating a lot of tables for no particular reason (to cover future years).

Thanks,
Michael

[Krzemo]

Which database engine you are going to use?

[dojobin]

In the first version, which will only be accessed from one machine, I'll just use MS Access. After the initial release, there's a chance I will need to have the database accessed from multiple client machines, which means I'll have to have a DB hosted on a server somewhere. In this case, I'll probably use something like MySQL or Postgres. I haven't thought that far ahead though.

[Krzemo]

Use MSDE (or SQL 2005 express) from microsoft, or firebird database (or MySQL or Postgres ... :rolleyes: but I think it can be more complicated). That way U save your time later (no need for rewriting application)

Best regards,
Krzemo.

[dojobin]

Thanks for the advice. The reason I chose Access was because I could just create the file and it would just work - no need to set up servers or anything like that. It's good for a standalone installation of my program.

So you think Access definitely won't be able to handle the load once a few entries are created? Can you think of any other way of structuring the database that would help (regardless of which database I end up using).

[Krzemo]

So you think Access definitely won't be able to handle the load once a few entries are created?Maybe few it can handle ..:rolleyes:
But with thousands it can get corrupt.

Can you think of any other way of structuring the database that would help For disscusion about similar problem look here:
http://www.codeguru.com/forum/showthread.php?t=324200

Best regards,
Krzemo.

[dojobin]

That was a very good read. Thanks :)

One more thing though - Now that you've convinced me to change databases, do you think having a single table where I just keep adding records one by one will be fine. I would say that there would be around 15000 records per year added, so I think that should be ok. Real databases are used to handling lots more than that right?

[Krzemo]

Now that you've convinced me to change databases..:cool: :thumb:
having a single table where I just keep adding records one by one will be fine. Yes.:thumb:
Real databases are used to handling lots more than that right? Right :thumb: !

Best regards,
Krzemo.
:wave: