database schema
Nick Tong
http://dev.talkwebsolutions.co.uk:81/trac/cfcommerce/wiki/ProposedSchema
--
Nick Tong
web: http://talkwebsolutions.co.uk
blog: http://succor.co.uk
f..works: http://cfframeworks.com
short urls: http://wapurl.co.uk
green link: http://wapurl.co.uk/?4Z2YDLX
Paul Marcotte
I'm in complete agreement for singular table names.
Paul
Paul Marcotte
Fancy Bread - in the heart or in the head?
http://www.fancybread.com
Chris Jordan
I'm guessing that with plurals getting shot down that this convention is probably not going to get used. So now I'm interested in what the naming convention will be for cross reference tables. I've got a friend who begins each cross reference table with 'lnk' (that's a lower case L). Following those lines I suppose that all cross reference tables could begin with 'xref' or perhaps 'x_' or maybe just 'x'.
Thoughts?
Chris
http://cjordan.us
Nick Tong
There are some nice pointers here: http://databases.aspfaq.com/database/what-naming-convention-should-i-use-in-my-database.html
Chris Jordan
Also -- and this not because I really care one way or another on plural vs. singular in general -- but the article you point to actively discourages naming tables in the singular with the reasoning that a table name describes a collection of rows. Like the author of that article, I generally think it's not necessary to put 'tbl' in front of every table name as well as to repeat the table name in each field in that table (though I've done that in the past, I've since decided that it's not what I think is a best practice)
Like I said though, clarification on cross reference table naming is what I'm really after. I've already stated that I like using plurals for that, but I'm open to other ideas since plurals don't seem to work for everyone. :o)
Chris
http://cjordan.us
Peter Bell
I tend not to love plurals. I get the semantic benefit that it indicated a collection, but I prefer the practical syntactic benefit of not wondering how to pluralize everything – I also like the fact that I can just re-use my object name as my table name where there is a “table per business object”.
I don’t prefix table names with tbl_. I have done so in the past. Main benefit in SQL server was that it moved all “real” tables next to each other, clearly distinguishing them from the system tables. These days I prepend table names with a project name (e.g. myproject_User) as my system supports sharing a database between projects. That said, I wouldn’t recommend that approach for this system unless there was a compelling requirement to be able to build n-CF stores all sharing a db (doesn’t sound compelling to me). I’d just suggest having User and Product as table names.
For join tables I have tried #ObjectName1#_#ObjectName2#, #ObjectName1#to#ObjectName2# and #ObjectName1#_to_#ObjectName2#. E.g.
Product_ProductCategory, ProducttoProductCategory or Product_to_ProductCategory. I quite like the “to” making it VERY clear it is a join table, am open to _’s (or -’s) for readability, but really still haven’t found something I completely love. I’m not a big fan of plurals for join tables, but I’d consistently use plurals or not use them for object names. I’d rather have Users and Companies_to_Users than User and Companies_to_Users, although my personal preference would be User and Company_to_User or similar.
Best Wishes,
Peter
On 10/31/07 2:48 PM, "Chris Jordan" <chris.s...@gmail.com> wrote:
I agree Nick, that we should have a convention and stick to it. I'm just trying to determine what that convention will be when it comes to naming cross reference tables.
Also -- and this not because I really care one way or another on plural vs. singular in general -- but the article you point to actively discourages naming tables in the singular with the reasoning that a table name describes a collection of rows. Like the author of that article, I generally think it's not necessary to put 'tbl' in front of every table name as well as to repeat the table name in each field in that table (though I've done that in the past, I've since decided that it's not what I think is a best practice)
Like I said though, clarification on cross reference table naming is what I'm really after. I've already stated that I like using plurals for that, but I'm open to other ideas since plurals don't seem to work for everyone. :o)
Chris
On 10/31/07, Nick Tong <nick...@gmail.com> wrote:
There are quite a few thoughts on this, table names beginning with tbl, views beginning with v etc. Again i think we have to have a rule and once that's set we stick to it.
There are some nice pointers here: http://databases.aspfaq.com/database/what-naming-convention-should-i-use-in-my-database.html
On 31/10/2007, Chris Jordan < chris.s...@gmail.com <mailto:chris.s...@gmail.com> > wrote:
I think I mentioned this somewhere (on the wiki, I think) -- that I use plurals only for cross reference tables. So I'd have a User table and an Order table and then a UsersOrders table.
I'm guessing that with plurals getting shot down that this convention is probably not going to get used. So now I'm interested in what the naming convention will be for cross reference tables. I've got a friend who begins each cross reference table with 'lnk' (that's a lower case L). Following those lines I suppose that all cross reference tables could begin with 'xref' or perhaps 'x_' or maybe just 'x'.
Thoughts?
Chris
On 10/31/07, Paul Marcotte < pmar...@gmail.com <mailto:pmar...@gmail.com> > wrote:
Dang, I missed that one!
I'm in complete agreement for singular table names.
Paul
On 10/31/07, Nick Tong < nick...@gmail.com <mailto:nick...@gmail.com> > wrote:
After a little discussion on http://www.succor.co.uk/index.cfm/2007/10/30/To-pluralise-or-not-to-pluralise i think we should not use plurals.
Chris Jordan
Chris
My 2c – for what it is worth (as these are really stylistic preferences) . . .
I tend not to love plurals. I get the semantic benefit that it indicated a collection, but I prefer the practical syntactic benefit of not wondering how to pluralize everything – I also like the fact that I can just re-use my object name as my table name where there is a "table per business object".
I don't prefix table names with tbl_. I have done so in the past. Main benefit in SQL server was that it moved all "real" tables next to each other, clearly distinguishing them from the system tables. These days I prepend table names with a project name ( e.g. myproject_User) as my system supports sharing a database between projects. That said, I wouldn't recommend that approach for this system unless there was a compelling requirement to be able to build n-CF stores all sharing a db (doesn't sound compelling to me). I'd just suggest having User and Product as table names.
For join tables I have tried #ObjectName1#_#ObjectName2#, #ObjectName1#to#ObjectName2# and #ObjectName1#_to_#ObjectName2#. E.g.
Product_ProductCategory, ProducttoProductCategory or Product_to_ProductCategory. I quite like the "to" making it VERY clear it is a join table, am open to _'s (or -'s) for readability, but really still haven't found something I completely love. I'm not a big fan of plurals for join tables, but I'd consistently use plurals or not use them for object names. I'd rather have Users and Companies_to_Users than User and Companies_to_Users, although my personal preference would be User and Company_to_User or similar.
Best Wishes,
Peter
On 10/31/07 2:48 PM, "Chris Jordan" <chris.s...@gmail.com> wrote:
I agree Nick, that we should have a convention and stick to it. I'm just trying to determine what that convention will be when it comes to naming cross reference tables.
Also -- and this not because I really care one way or another on plural vs. singular in general -- but the article you point to actively discourages naming tables in the singular with the reasoning that a table name describes a collection of rows. Like the author of that article, I generally think it's not necessary to put 'tbl' in front of every table name as well as to repeat the table name in each field in that table (though I've done that in the past, I've since decided that it's not what I think is a best practice)
Like I said though, clarification on cross reference table naming is what I'm really after. I've already stated that I like using plurals for that, but I'm open to other ideas since plurals don't seem to work for everyone. :o)
Chris
On 10/31/07, Nick Tong <nick...@gmail.com> wrote:
There are quite a few thoughts on this, table names beginning with tbl, views beginning with v etc. Again i think we have to have a rule and once that's set we stick to it.
There are some nice pointers here: http://databases.aspfaq.com/database/what-naming-convention-should-i-use-in-my-database.html
On 31/10/2007, Chris Jordan < chris.s...@gmail.com <mailto:chris.s...@gmail.com> > wrote:
I think I mentioned this somewhere (on the wiki, I think) -- that I use plurals only for cross reference tables. So I'd have a User table and an Order table and then a UsersOrders table.
I'm guessing that with plurals getting shot down that this convention is probably not going to get used. So now I'm interested in what the naming convention will be for cross reference tables. I've got a friend who begins each cross reference table with 'lnk' (that's a lower case L). Following those lines I suppose that all cross reference tables could begin with 'xref' or perhaps 'x_' or maybe just 'x'.
Thoughts?
Chris
On 10/31/07, Paul Marcotte < pmar...@gmail.com <mailto:pmar...@gmail.com> > wrote:
Dang, I missed that one!
I'm in complete agreement for singular table names.
Paul
On 10/31/07, Nick Tong < nick...@gmail.com <mailto:nick...@gmail.com> > wrote:
After a little discussion on http://www.succor.co.uk/index.cfm/2007/10/30/To-pluralise-or-not-to-pluralise i think we should not use plurals.
http://dev.talkwebsolutions.co.uk:81/trac/cfcommerce/wiki/ProposedSchema <http://dev.talkwebsolutions.co.uk:81/trac/cfcommerce/wiki/ProposedSchema>
--
http://cjordan.us
Nick Tong
Gareth Arch
as it's been kinda quiet on here lately). Not sure what the next step
is for this project.
On Oct 31, 3:41 pm, "Nick Tong" <nickt...@gmail.com> wrote:
> Okay so we're nearing an end. We should tick to singular table name and
> cross references tables shoudl use the 'to' string.
>
> On 31/10/2007, Chris Jordan <chris.s.jor...@gmail.com> wrote:
>
>
>
>
>
> > I could certainly get on board with a 'Company_to_User' or even
> > CompanyToUser type of convention for cross reference tables. I recently had
> > to use a database structure that someone else created and while I didn't
> > *love* it, it was at least consistent. It was also crystal clear that
> > tblname1_to_tblname2 was a join table. So, I'm completely okay with that
> > sort of convention. Actually, I can't believe I didn't think to suggest it
> > myself. I'm working with it *right now* for cryin' out loud! :o)
>
> > Chris
>
> > On 10/31/07, Peter Bell <pb...@systemsforge.com> wrote:
>
> > > My 2c - for what it is worth (as these are really stylistic
> > > preferences) . . .
>
> > > I tend not to love plurals. I get the semantic benefit that it indicated
> > > a collection, but I prefer the practical syntactic benefit of not wondering
> > > how to pluralize everything - I also like the fact that I can just re-use my
> > > object name as my table name where there is a "table per business object".
>
> > > I don't prefix table names with tbl_. I have done so in the past. Main
> > > benefit in SQL server was that it moved all "real" tables next to each
> > > other, clearly distinguishing them from the system tables. These days I
> > > prepend table names with a project name ( e.g. myproject_User) as my
> > > system supports sharing a database between projects. That said, I wouldn't
> > > recommend that approach for this system unless there was a compelling
> > > requirement to be able to build n-CF stores all sharing a db (doesn't sound
> > > compelling to me). I'd just suggest having User and Product as table names.
>
> > > For join tables I have tried #ObjectName1#_#ObjectName2#,
> > > #ObjectName1#to#ObjectName2# and #ObjectName1#_to_#ObjectName2#. E.g.
> > > Product_ProductCategory, ProducttoProductCategory or
> > > Product_to_ProductCategory. I quite like the "to" making it VERY clear it is
> > > a join table, am open to _'s (or -'s) for readability, but really still
> > > haven't found something I completely love. I'm not a big fan of plurals for
> > > join tables, but I'd consistently use plurals or not use them for object
> > > names. I'd rather have Users and Companies_to_Users than User and
> > > Companies_to_Users, although my personal preference would be User and
> > > Company_to_User or similar.
>
> > > Best Wishes,
> > > Peter
>
> > > On 10/31/07 2:48 PM, "Chris Jordan" <chris.s.jor...@gmail.com> wrote:
>
> > > I agree Nick, that we should have a convention and stick to it. I'm just
> > > trying to determine what that convention will be when it comes to naming
> > > cross reference tables.
>
> > > Also -- and this not because I really care one way or another on plural
> > > vs. singular in general -- but the article you point to actively discourages
> > > naming tables in the singular with the reasoning that a table name describes
> > > a collection of rows. Like the author of that article, I generally think
> > > it's not necessary to put 'tbl' in front of every table name as well as to
> > > repeat the table name in each field in that table (though I've done that in
> > > the past, I've since decided that it's not what I think is a best practice)
>
> > > Like I said though, clarification on cross reference table naming is
> > > what I'm really after. I've already stated that I like using plurals for
> > > that, but I'm open to other ideas since plurals don't seem to work for
> > > everyone. :o)
>
> > > Chris
>
> > > On 10/31/07, *Nick Tong* <nickt...@gmail.com> wrote:
>
> > > There are quite a few thoughts on this, table names beginning with tbl,
> > > views beginning with v etc. Again i think we have to have a rule and once
> > > that's set we stick to it.
>
> > > There are some nice pointers here:http://databases.aspfaq.com/database/what-naming-convention-should-i-...
>
> > > On 31/10/2007, *Chris Jordan* < chris.s.jor...@gmail.com
> > > <mailto:chris.s.jor...@gmail.com> <chris.s.jor...@gmail.com> > wrote:
>
> > > I think I mentioned this somewhere (on the wiki, I think) -- that I use
> > > plurals only for cross reference tables. So I'd have a User table and an
> > > Order table and then a UsersOrders table.
>
> > > I'm guessing that with plurals getting shot down that this convention is
> > > probably not going to get used. So now I'm interested in what the naming
> > > convention will be for cross reference tables. I've got a friend who begins
> > > each cross reference table with 'lnk' (that's a lower case L). Following
> > > those lines I suppose that all cross reference tables could begin with
> > > 'xref' or perhaps 'x_' or maybe just 'x'.
>
> > > Thoughts?
>
> > > Chris
>
> > > On 10/31/07, *Paul Marcotte* < pmarco...@gmail.com
> > > <mailto:pmarco...@gmail.com> <pmarco...@gmail.com> > wrote:
>
> > > Dang, I missed that one!
>
> > > I'm in complete agreement for singular table names.
>
> > > Paul
>
> > > On 10/31/07, *Nick Tong* < nickt...@gmail.com
> > > <mailto:nickt...@gmail.com> <nickt...@gmail.com> > wrote:
>
> > > After a little discussion on
> > >http://www.succor.co.uk/index.cfm/2007/10/30/To-pluralise-or-not-to-p...think we should not use plurals.
Chris Jordan
Chris
Paul Marcotte
I promised to sketch out some UML diagrams for this week, but was completely distracted with trying to simplify using MVC without a framework (yeah, I'm a masochist).
Some diagrams are forthcoming and it's my hope that we work from the object model down to the data model instead of the other way around. I realize that this is a stretch for most folks (myself included), but I think that it will have a positive end result for all. If for no other reason then to learn something new. :)
Cheers,
Paul
Chris Jordan
Chris
http://cjordan.us
Paul Marcotte
Yeah, that's what I'm getting at. I was really reluctant to bring this up, because it sounds rather elitist, but I hope that we can approach the design phase as a process. Something like this:
1. define the interface (a view or screen) that the user will interact with (a wireframe or simple mock-up would be help - I'm pretty visually centered)
2. define the objects that make up the interface
3. sketch a diagram of how the objects are related
4. define the methods and properties of the objects
The properties of the object are typical candidates for table attributes. I would likely define the data types and rules for the properties as a part of the db schema definition, rather than try and cram that all into a UML diagram.
Now, I'm going to say it up front, I've never followed this process in the past. I've always started with an E/R diagram. The steps above are one way of approaching design, but there is no "right way". It's the way that fits the team skillset.
Also, I might have left out some steps, or even have them in the wrong order (the more experienced folks, please step in any time).
So, uh, that said, I'm not suggesting that the schema page is wrong and I don't want to minimize anyone's contribution. In the end, it might look exactly the way it is right now. What I'm suggesting is that we make an effort to formalize a design approach, stick with it and hopefully build some great, maintainable, resuable software.
Chris Jordan
That sounds logical to me for designing a user interface. What about back end work? By that I suppose I mean the layer that handles the business logic that isn't necessarily logically linked to a view or screen?
I'm trying to think of a good example right now, but nothing is leaping to mind right now (having a bit of trouble multi-tasking today)... but does that sound like a valid question?
http://cjordan.us
Paul Marcotte
Good question. The way that I look at it is that you have two models. A domain model for your objects like cart, product, customer and an application model that provides the infrastructure for creating and managing the domain objects (a DAO, Service, Gateway). Often the majority of the business logic is placed in a "Service" object. This can lead to an "anti-pattern" called anemic domain model, where your domain objects don't do much besides encapsulating a record from the database. The trick is to strike a balance between the business logic in your domain and application model.
I've thought about this stuff a lot for almost a year now and read everything I can think of to try to understand it all. It's just starting to gel in my head after a lot of trial and error. The thing about taking an object oriented approach to designing a web application is that there's so much to learn and understand that often you don't know why a particular pattern or approach solves a problem until you face the problem without using OO.
That's a bit of a ramble, but I hope it clears things up slightly.
Peter Bell
I’m going to suggest an approach that works very well for my apps and I think may be valid for this too. Think of an application as a black box. All it has to do is to respond correctly with the right outputs for the right inputs. Thus you can fully define the system by describing all of the inputs and outputs. Because of that, I usually just list all of the use cases, all of the screens and actions for each, and then use that as the basis of the system.
Of course, you have to include log files, imports, exports, scheduled tasks and APIs as interfaces – not just HTML views/controller actions.
For very rich or complex domains or applications with a lot of internal logic or very few UI elements, it isn’t a good fit, but for web apps I have found it works quite well. What it helps with is that it remind you that you don’t have to model every theoretical possible relationship between different objects – if a relationship isn’t used by an action or a screen, you don’t need to include it in the model.
I’ve found this approach works quite well for my use cases. Would be interested in getting others feedback for this project . . .
Best Wishes,
Peter
On 11/5/07, Chris Jordan < chris.s...@gmail.com <mailto:chris.s...@gmail.com> > wrote:
Paul,
That sounds logical to me for designing a user interface. What about back end work? By that I suppose I mean the layer that handles the business logic that isn't necessarily logically linked to a view or screen?
I'm trying to think of a good example right now, but nothing is leaping to mind right now (having a bit of trouble multi-tasking today)... but does that sound like a valid question?
Chris
On 11/5/07, Paul Marcotte <pmar...@gmail.com> wrote:
Hi Chris,
Yeah, that's what I'm getting at. I was really reluctant to bring this up, because it sounds rather elitist, but I hope that we can approach the design phase as a process. Something like this:
1. define the interface (a view or screen) that the user will interact with (a wireframe or simple mock-up would be help - I'm pretty visually centered)
2. define the objects that make up the interface
3. sketch a diagram of how the objects are related
4. define the methods and properties of the objects
The properties of the object are typical candidates for table attributes. I would likely define the data types and rules for the properties as a part of the db schema definition, rather than try and cram that all into a UML diagram.
Now, I'm going to say it up front, I've never followed this process in the past. I've always started with an E/R diagram. The steps above are one way of approaching design, but there is no "right way". It's the way that fits the team skillset.
Also, I might have left out some steps, or even have them in the wrong order (the more experienced folks, please step in any time).
So, uh, that said, I'm not suggesting that the schema page is wrong and I don't want to minimize anyone's contribution. In the end, it might look exactly the way it is right now. What I'm suggesting is that we make an effort to formalize a design approach, stick with it and hopefully build some great, maintainable, resuable software.
Paul
> > > There are some nice pointers here: http://databases.aspfaq.com/database/what-naming-convention-should-i-. <http://databases.aspfaq.com/database/what-naming-convention-should-i-.> ..
>
> > > On 31/10/2007, *Chris Jordan* < chris.s.jor...@gmail.com
> > > <mailto: chris.s.jor...@gmail.com> < chris.s.jor...@gmail.com <mailto:chris.s.jor...@gmail.com> > > wrote:
>
> > > I think I mentioned this somewhere (on the wiki, I think) -- that I use
> > > plurals only for cross reference tables. So I'd have a User table and an
> > > Order table and then a UsersOrders table.
>
> > > I'm guessing that with plurals getting shot down that this convention is
> > > probably not going to get used. So now I'm interested in what the naming
> > > convention will be for cross reference tables. I've got a friend who begins
> > > each cross reference table with 'lnk' (that's a lower case L). Following
> > > those lines I suppose that all cross reference tables could begin with
> > > 'xref' or perhaps 'x_' or maybe just 'x'.
>
> > > Thoughts?
>
> > > Chris
>
> > > On 10/31/07, *Paul Marcotte* < pmarco...@gmail.com
> > > <mailto: pmarco...@gmail.com <mailto:pmarco...@gmail.com> > <pmarco...@gmail.com> > wrote:
>
> > > Dang, I missed that one!
>
> > > I'm in complete agreement for singular table names.
>
> > > Paul
>
> > > On 10/31/07, *Nick Tong* < nickt...@gmail.com
> > > <mailto:nickt...@gmail.com <mailto:nickt...@gmail.com> > <nickt...@gmail.com> > wrote:
>
> > > After a little discussion on
> > > http://www.succor.co.uk/index.cfm/2007/10/30/To-pluralise-or-not-to-p...think we should not use plurals.
>
> > > http://dev.talkwebsolutions.co.uk:81/trac/cfcommerce/wiki/ProposedSchema <http://dev.talkwebsolutions.co.uk:81/trac/cfcommerce/wiki/ProposedSchema>
> > http://cjordan.us <http://cjordan.us>
>
> --
> Nick Tong
>
> web: http://talkwebsolutions.co.uk <http://talkwebsolutions.co.uk>
> blog: http://succor.co.uk <http://succor.co.uk>
> f..works: http://cfframeworks.com
> short urls: http://wapurl.co.uk
> green link: http://wapurl.co.uk/?4Z2YDLX <http://wapurl.co.uk/?4Z2YDLX>
Chris Jordan
So, should we (the cfComerce Team and anyone else who wants to) pick one of the modules and dive in? Or should we further discuss what exact approach we will take before we all get going too far? I suppose it's entirely possible for different modules in the project to take different approaches as long as each delivers an API that others can use, right?
I think that cfCatalog or maybe cfCustomer would be an easy place to start. I've got to head home. I'll get online once I get home to check the list and perhaps offer a couple of wire frame/mock-up sort of screens.
http://cjordan.us
Chris Jordan
That sounds real close to what Paul was saying with the addition of use cases. I like what you said about those helping to sort out which relationships between objects need to be mapped and which ones can be left out.
Chris
http://cjordan.us
Paul Marcotte
@Peter, thanks for the black box analogy. I'd like to follow your approach for starting with use cases. The first module I wanted to work on/model is cfCart. Let's give it a code name and call it "blackCart". Do you mind getting the ball rolling with some use cases and I'll try to roll that into a UML class diagram? I'd offer to create a use case diag., but I don't get them... :(
Paul
Gareth Arch
here and I was kinda stuck with where to go next so I figured I'd get
something down even if it was going to be scrapped eventually :)
I think the use case for a shopping cart would be very basic
(especially since we're modularizing everything after the cart and use
cases are supposed to be pretty minimalistic generally). I added my
attempt into a new ticket on the TRAC
http://dev.talkwebsolutions.co.uk:81/trac/cfcommerce/ticket/3
On Nov 5, 6:12 pm, "Paul Marcotte" <pmarco...@gmail.com> wrote:
> @Chris, yes, by all means dive in. I'm glad Nick put together the
> wireframe thingy, I've never used it before, so that's a bonus for me.
>
> @Peter, thanks for the black box analogy. I'd like to follow your approach
> for starting with use cases. The first module I wanted to work on/model is
> cfCart. Let's give it a code name and call it "blackCart". Do you mind
> getting the ball rolling with some use cases and I'll try to roll that into
> a UML class diagram? I'd offer to create a use case diag., but I don't get
> them... :(
>
> Paul
>
> On 11/5/07, Chris Jordan <chris.s.jor...@gmail.com> wrote:
>
>
>
> > Peter,
>
> > That sounds real close to what Paul was saying with the addition of use
> > cases. I like what you said about those helping to sort out which
> > relationships between objects need to be mapped and which ones can be left
> > out.
>
> > Chris
>
> > On 11/5/07, Peter Bell <pb...@systemsforge.com> wrote:
>
> > > Hi Chris,
>
> > > I'm going to suggest an approach that works very well for my apps and I
> > > think may be valid for this too. Think of an application as a black box. All
> > > it has to do is to respond correctly with the right outputs for the right
> > > inputs. Thus you can fully define the system by describing all of the inputs
> > > and outputs. Because of that, I usually just list all of the use cases, all
> > > of the screens and actions for each, and then use that as the basis of the
> > > system.
>
> > > Of course, you have to include log files, imports, exports, scheduled
> > > tasks and APIs as interfaces - not just HTML views/controller actions.
>
> > > For very rich or complex domains or applications with a lot of internal
> > > logic or very few UI elements, it isn't a good fit, but for web apps I have
> > > found it works quite well. What it helps with is that it remind you that you
> > > don't have to model every theoretical possible relationship between
> > > different objects - if a relationship isn't used by an action or a screen,
> > > you don't need to include it in the model.
>
> > > I've found this approach works quite well for my use cases. Would be
> > > interested in getting others feedback for this project . . .
>
> > > Best Wishes,
> > > Peter
>
> > > On 11/5/07, *Chris Jordan* < chris.s.jor...@gmail.com
> > > <mailto:chris.s.jor...@gmail.com> <chris.s.jor...@gmail.com> > wrote:
>
> > > Paul,
>
> > > That sounds logical to me for designing a user interface. What about
> > > back end work? By that I suppose I mean the layer that handles the business
> > > logic that isn't necessarily logically linked to a view or screen?
>
> > > I'm trying to think of a good example right now, but nothing is leaping
> > > to mind right now (having a bit of trouble multi-tasking today)... but does
> > > that sound like a valid question?
>
> > > Chris
>
> > > On 11/5/07, *Chris Jordan* < chris.s.jor...@gmail.com
> > > <mailto:chris.s.jor...@gmail.com> <chris.s.jor...@gmail.com> > wrote:
>
> > > Thanks, Paul. I'm totally up for designing from the model down. I'm
> > > guessing that you're referring to the table schema that's been showing up on
> > > the wiki, as evidence that we may be trying to do things the other way
> > > round. Right?
>
> > > Chris
>
> > > On 11/5/07, *Paul Marcotte* < pmarco...@gmail.com
> > > <mailto:pmarco...@gmail.com> <pmarco...@gmail.com> > wrote:
>
> > > Hey gents,
>
> > > I promised to sketch out some UML diagrams for this week, but was
> > > completely distracted with trying to simplify using MVC without a framework
> > > (yeah, I'm a masochist).
>
> > > Some diagrams are forthcoming and it's my hope that we work from the
> > > object model down to the data model instead of the other way around. I
> > > realize that this is a stretch for most folks (myself included), but I think
> > > that it will have a positive end result for all. If for no other reason
> > > then to learn something new. :)
>
> > > Cheers,
>
> > > Paul
>
> > > On 11/5/07, *Chris Jordan* < chris.s.jor...@gmail.com
> > > <mailto:chris.s.jor...@gmail.com> <chris.s.jor...@gmail.com> > wrote:
>
> > > I'm with you Gareth. Since this is my first time working on a project
> > > like this, I'm unsure of what the next step should be. A UML diagram of our
> > > object model? Which module(s) should we tackle first? Do we need to be sure
> > > that everyone has the proper tools for collaborating?
>
> > > Chris
>
> ...
>
> read more »