> Simon Slavin wrote:
>
>
> I'm not sure you appreciate what Roger (please be more careful about
> your quoting, by the way) is telling you. SQL is not a programming
> language. It's a way of accessing a database. The two are not at all
> equivalent: everything you can do in SQL you can do in any good
> programming language, but not vice versa.
>
>
> You're being urged to write your program, not to try to use as many
> SQL tricks as you can.
>
Hmm... Sorry if I mis-quoted.... thought I had it right.
Indeed, I am aware that SQL is not a "traditional" programming language per-se
and have will now be writing the calendar logic at the application level.
(Looking at Python...)
In this application, there are going to be a very large number of concurrent
"readers" that want to know at any given time who is doing what. Where "doing
what" is defined as the most specific event the user currently has scheduled.
The "event table" I have been asking about is something that I envision my app
will generate on a daily/hourly basis as the *output* of all the calendering
logic. In this way, I hope to let sqlite, and eventually an SQL server, handle
all the multi-user connection and scaling issues. This is also especially
useful as there is other data in the DB that will need to be retrieved anyway
for every currently active event. (This is why I am trying to generate that
list of event IDs inside the DB to start with.)
> Write code to manipulate dates and times, to
> implement repeating events, and to present a decent user-interface to
> your users. SQL is going to do lots of work for you but it's not
> going to come up with all the answers you want. Sooner or later
> you're going to have to do some filtering or sorting in your software.
>
Indeed,
Thank you for your help,
:)
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
