Thanks Diez, always clear and concise advice. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Diez B. Roggisch Sent: Sunday, May 30, 2010 10:29 AM To: [email protected] Subject: Re: [TurboGears] New Application; seeking experienced advice
Hi, please don't hijack threads, post new ones if you have a new topic. Comments see below. > > 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. None of this is related to TG1 or TG2, so it's up to you what weapon you chose. I personally wouldn't go for the 500 column row, for a range of reasons: - no not-null constraints - a beast to work with in any SQL-related tool - also a massive monster of a declaration in SQLAlchemy (unless you reflect of course) - no domain/subclass specific model code, one of the advantages of ORMs So depending on your actual requirement, I would implement this as either a core table with a lot of sub-tables that relate to it and make the whole thing an aggregation, or if things are compatible withe a single-inheritance-model, use inheritance. My gut feeling says me though that's not really an option. > > 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) Don't deal with conflicts. First, don't care at all. If the really create problems, go for an optimistic locking strategy, potintially with somo ajaxy (or whatever the equivalent in flex is) status-polling that tells a user that the record she works on was modified in the meantime. After all, if these things are really a problem, it's much more an organizational matter than a technical. Why are people working together on the same thing at the same time, does it make sense to split out certain data again into subsets and so forth... > > 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. I'd say stick with TG2.0, but I'm not totally up to date with the latest and greatest in TG21, others might have different opinion here. > > > 2. Will I encounter documentation "shortfalls" with 2.1 compared to > 2.0. No idea, I almost always only read code :) > > 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? See above. > > 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? I don't think so. > > 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? Not sure what you mean, this depends massively on what you consider a template, how it's implemented and so forth. I'd say given the dynamic natuer of python, you should be able to come up with a declarativ enough solution. Diez -- 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. -- 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.
