I must be missing something because I don't see any problem. For
example, you have a combo box with CATEGORY names displayed. When your
user selects a name, your SELECT statement would match the MATERIAL
foreign key to the CATAGORY primary key (using your dictionary) and
display the appropriate MATERIAL string. Is this not what you want?
And, each row in the grid has a different CATEGORY?
That's not quite what I had in mind.
Here are a few sample CATEGORY records:
rsn | Name
001 | Steel
002 | Aluminum
003 | Electical
And some matching MATERIAL records:
rsn | cat | Name
001 | 001 | 4' by 8' by 0.25"
002 | 001 | 4' by 10' by 0.25"
003 | 002 | 4' by 8' by 0.25"
004 | 002 | 4' by 10' by 0.25"
005 | 003 | 20A panel
006 | 004 | duplex outlet
The grid in question will show all MATERIAL records (there will be only
a couple hundred). They will be retrieved from the database with a
single query: 'select rsn, cat, Name from MATERIAL'
However, instead of displaying the integer values for the category
column, I want to display the name
rsn | category | Name
001 | Steel | 4' by 8' by 0.25"
002 | Steel | 4' by 10' by 0.25"
003 | Aluminum | 4' by 8' by 0.25"
004 | Aluminum | 4' by 10' by 0.25"
005 | Electrical | 20A panel
006 | Electrical | duplex outlet
When the user edits the category column, they do so by a drop down list.
An alternative would be to select the rows with a join to get category
names: select m.rsn, c.name, m.name from MATERIAL m join CATEGORY c
on ...
Then use just user the drop down list to force the user to select a
valid category and then translate from the category string to it's RSN
in the process that writes the rows to the database.
IIRC, wxPython implements the MVC concept imperfectly. And, there
are valid situations when de-normalizing relational database tables is
also justified for speed and ease of use. What works ought to be the
determining criterion.
I agree. After composing this reply, I'm considering storing the
category string directly in the MATERIAL table. In this application,
the only advantage of normalizing the category name is to allow the
category name to change and that's unlikely enough that it could be
handled with a mass update: update material set c_name=<NEW CATEGORY>
where c_name = <OLD CATEGORY>
Mark
···
On Wed, 2008-01-02 at 15:11 -0800, Rich Shepard wrote: