On Monday, July 21, 2014 8:38:54 AM UTC-7, Jonathan Vanasco wrote: > > 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. > <snip> >
Short answer: manufacturer/model tables are projectors, and sources are the video inputs available for that particular model. The sources table is going to be used to keep track of what the manufacturer has listed in their documentation for selecting a particular video source. The projectors_table is persistent storage use for what projectors that the user can control via networking. Basic information is some text columns that the end-user can assign for their own (short) notes, but the model_id field is used so that the text can be matched with the projector that they have control over. Longer answer. Column 1 is PJLink code for selecting that input, the rest of the line is text. Example for Eiki model LC/XL200 projector: (Text is from Eiki webpage control) 11 "RGB (pc analog)" 12 "RGB (Scart)" 13 "RGB (PC Digital)" Example Hitachi CP-X2514: (Text is from PJLink user manual from Hitachi) 11 "Computer IN 1" 12 "Computer IN 2" 13 "Component" As noted, different manufacturers may have different text for the same inputs, so the sources table is just keeping track of the text for the input source - hopefully text that the end-user does not find too confusing :) This is not an inventory program. The part I'm looking to add is basic projector control to a program that will send some output via a second computer video output to a projector. One point is that there may be multiple computers connected to a single projector via multiple inputs (sources). I was thinking of having manufacturer/model/source tables so the end-user doesn't have to re-enter the information if they just happen to have multiple projectors with the same model - as a side possibility, also having an xml file with this information available that can be imported into those tables. When the end-user adds a projector to the program, they can select the projector by manufacturer (Eiki) -> model (LC/XL200) - then the sources (video inputs) would be added to the projector class so they can then select the video source to display. Since using PJLink codes would be confusing ("What does input 11 select?"), the text pulled from the sources table would then let them use the familiar text (documented in their projector user manual - like "RGB (pc analog)" ) to select the source. An example xml file for importing would look something like: <projector manufacturer='Eiki'> <model name='LC/XL200'> <source pjlink='11'>RGB (PC analog)</source> <source pjlink='12'>RGB (Scart)</source> <source pjlink='13'>RGB (PC digital)</source> </model> <model name=.'...'> .... </model> </projector> With the importing in mind, there still has to be the option for the end-user to manually add an entry for projector manufacturer/model/sources (technical note, with PJLink, I can retrieve the manufacturer name, model name, and the available sources via the network, just not the text for the sources). With that, then Jonathan's suggestion of removing the foreign_key on the sources table and create a 4th table that keeps track of the model<->sources constraints. As for the projectors_table, instead of a foreign_key just use an integer column as an index into the models_table would be the suggestion? projector_table = Table(u'projector', metadata, Column(u'id', Integer, primary_key=True), Column(u'model_2_source_id', Integer) ) The way things are looking, looks like I'm going to have multiple selects. Not an issue, since they will only be used on program startup, not during normal operations. -- 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.