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.
