I have a new internal app to build starting June 1 with Beta Sept 1 and production deploy Oct 1. I'm an old hand at Python and MySQL with a little TG 1.0.4 and SQLObject but no SQLAlchemy.
I'm planning to use Flex for the UI and have TG pass it XML. I've already got the Flex completed. Worst case scenario is 100 simultaneous users organized into 20 autonomous divisions and no one making rapid changes. I'll be using CentOS and MySQL 5.0 on virtual servers with as much RAM as I need. Performance is not an issue. Each logical record contains about 500 fields which may be cleanly grouped into about 20 sections. Not all fields apply to all records and this is determined from a template when the record is created. The Create, Copy, Delete, Validate and Print functions will need access to all 500 fields while Edit will address one 1 section at a time. One geographical region (state) as a supplement section "S" with about 5 fields; however due to schedule constraints I could incorporate it into the generic DB and just put NULL's in its values for the other regions so it could be ignored. Not pretty but this is a stop-gap task. It would be "nice" to prevent simultaneous edits of the same section in the same record, but the schedule constraints would allow me to ignore that issue and just tell users "don't do that" (yes that's operationally feasible) I am hoping to avoid any major design mistakes that could require significant rework, so my questions are: 1. Are there any features that would cause me to choose TG 2.1 over 2.0 other than the release status of 2.1? Especially given that I'm using Flex and not Genshi. 2. Will I encounter documentation "shortfalls" with 2.1 compared to 2.0. 3. Should I use one huge (500 column) MySQL table and then define models for editing the different sections to minimize joins or should I map the sections to tables to make it more modular? 3.a. I can use one table with 500 columns and then use MySQL "INSERT INTO active SELECT * from template where datatype=3" type of syntax to create a new record with the appropriate NULL's for the non-applicable fields. A Copy function will have to examine the NULL's in the record introduced by the template, so each field must be examined individually. 3.b. Are there any SQLAlchemy issues with large tables? 3.c. Is there a Pythonic way to copy all the fields from a template into a record in SQLAlchemy without iterating through all the fields? Any insight would be greatly appreciated. -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
