I agree with what Mike said, but I would just suggest renaming
"projector_table" to something like "purchased_table" or "inventory_table".
Everything in "models" is a different model of a projector, so the table
names are a bit confusing.
In non-database terms, a good way to visualize relationships is to think of
a form on a webpage. If you expect to select items from a "dropdown"
select menu, then those things are usually best as something your
foreign-key into their own table (or perhaps some sort of enumerated value,
but that's another topic). If something is a bit of freeform text you
enter, then it belongs in a column. You can also think of ways you'd want
to search or display data. You might want to show projectors that only
match a specific MFG, or have a specific type of source. Both of those
requirements suggest having a seperate table with a foreign key might be a
good idea ( vs a fulltext search )
That said, I'm unclear about what "sources" are.
If a "source" is an AV input, then the source "types" would be global and
shared. So a more normalized DB would have the sources in:
sources_table = Table(u'source', metadata,
Column(u'id', Integer, primary_key=True),
Column(u'label', String(20)),
)
model_2_source_table = Table(u'model_2_source', metadata,
Column(u'model_id', Integer, primary_key=True,
ForeignKey(u'model.id'),
Column(u'source_id', Integer, primary_key=True,
ForeignKey(u'source.id' ),
)
If a "source" is a local input in your building though, then you would want
to associate the 'source' with the inventory item you are tracking.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
