[Tutor] Proper SQLite cursor handling?
boB Stepp
robertvstepp at gmail.com
Tue Jul 6 20:16:11 EDT 2021
On Tue, Jul 6, 2021 at 7:03 PM Cameron Simpson <cs at cskk.id.au> wrote:
>
> On 06Jul2021 10:06, Alan Gauld <alan.gauld at yahoo.co.uk> wrote:
> >On 06/07/2021 01:20, boB Stepp wrote:
> >> Each one of these solitaire games would have its own collection of
> >> hands played over time and look like:
> >>
> >> boBSolitair
> >> =========
> >> hand_num | date_played | time_recorded | hand_score
> >> ==========================================
> >> 1 | 2021-07-04 | 1342 | -5
> >> 2 | 2021-07-04 | 1356 | 43
> >> 3 | 2021-07-05 | 0704 | -26
> >> 4 ...
> >>
> >> Likewise "boBSolitair2" and "AlanSolitair1" would have their own hands
> >> played tables.
> >This is the bit swe are saying is suspect.
> >Rather than a hands table per game type just make game
> >type a field of a single hands table.
>
> Just to this, a normal approach would be a single table with an
> additional game_id column. A specific hand is then identified by the
> (game_id,hand_num) tuple. A whole game would be all hands with a
> particular game_id value.
>
> This is what the "relational" in RDBMS is for - SELECT lets you pull out
> all sorts of things based on these relationships.
>
> So a "table" is normally one-for-one with a record type - you'd have one
> "hands" table for all "hand records" above. A particular game is just an
> abstraction on top of that. Like any other subset eg high scoring hands,
> or hands played on a particular date, etc.
Yeah, after Dennis' posts I started to (vaguely) recall this stuff. I
had forgotten that I need a different mindset about data and their
interrelationships in RDBMSs that SQL then exploits. I just broke out
one of my newer SQL books and will probably be reading through that
for a while as I do not recall this stuff well enough obviously. This
will be overkill for the current project, but beneficial for later,
more substantial ones.
Cheers!
boB Stepp
More information about the Tutor
mailing list