From: Adrian C. <ad...@da...> - 2003-04-27 13:21:13
Attachments:
DPGSyntaxDBfieldsanddatatypestable.doc
|
Hi Syntax users, We've recently installed Syntax on our server and have been planning the database according to our website's content needs. We've been struggling to understand the best way to customise the software and would really appreciate some help. Attached is a word document containing a table that outlines our plan so far for the database tables, indicating the fields of each datatype, and our basic database fields as well. The first column - Database fields is the fields of the database. The second column - Fieldtype is the type of content that field will contain. The third column - Event DataType Field and other columns with '+' or 'x' in indicate whether that database field is relevant for each of the datatypes. The Event Datatype Field Description column and Music DB field description, etc indicate what that database field is used for in each datatype. I understand that Syntax works best is for there to be a minimum number of fields in the database by repurposing fields that are used for a specific purpose in one datatype (Eg, the Events datatype), for use in another datatype (Eg, the Music datatype). That occurs for DB field Date3 in the attached document - the fields are called different names in the different datatypes. So basically I have tried to have the least number of DB fields by repurposing the fields used by the different datatypes in other datatypes to some extent but am finding it a real mental exercise. Would anyone mind taking a look at the document and checking out the DB fields in the left hand side column labelled "MUSIC and EVENTS", and the items labelled "PEOPLE, PLACES, and ORGANISATIONS", and see if you can see which if any of the fields can be re-purposed between these two groups of datatypes? Or if anyone can offer a better strategy for this normaization process that would be fantastic. I also understand that Syntax needs datatypes to have identical field types for this to work. All of this seems very difficult to do quickly, and our project's deadline is very soon. I'm guessing we could just set up the db with as many fields as needed by the different datatypes (even if some fields will be used in only one or two datatypes) and then cut out irrelevant fields one-by-one as we find matches along the way. Is that correct (or do we absolutely need to repurpose all fields among the different datatypes wherever possible from the very start)? Are we on the right track? Regards, Adrian |
From: Sandy S. <ss...@fo...> - 2003-04-30 16:25:47
|
Hi Adrian-- I took a brief look at your table. I may be able to look longer tonight for more specific suggestions, but for the moment: You may want to consider using Syntax's facility for relating datatypes to one another. The clearest areas I see for this are your Area/Side 1 Name and Info fields. Instead I would suggest using DBasis to set up two new objects: Area and Side. Then define fields for each, Name and Information (probably mapped to name and desc1), and so on. Then define two new relationships: Event to Area and Music to Side. Then modify your Event datatype to have an Areas attribute (clicking the Multiple checkbox) and select the Event to Area relationship. Modify the Music datatype to have a Sides attribute (clicking the Multiple checkbox) and select the Music to Side relationship. The consuming code is a little more complex, but as you will see from the API the pxdb_record object is fairly good about giving you shortcuts to get related objects. The advantage of this approach, besides making your records table much less complex, is that it allows not just 4 areas or sides, but n areas and n sides. To get user submissions, you can create a wizard to allow people too submit an event and then add areas until they're done. In Context, your admins can create the areas and sides and then modify the Event and Music objects to include them as needed. One note is that you will want to make the relationship bidirectional, so you can add an Event single relationship in the Area datatype, and create your additional areas and relate them to their event in one step. It's useful to keep the relationship in the Event object so you can both see associated areas when you are editing the Event object and use an event pxdb_record object to get related Areas. If you do a similar decomposition of your other datatypes (or fields in the Music and Event datatypes, such as related shopping items), you might avoid some of this complexity. However, I do find that occasional projects will force me to add one or two extra columns to the records table. Hope that helps, Sandy On Sunday, April 27, 2003, at 09:15 AM, Adrian Columb wrote: > Hi Syntax users, > > We've recently installed Syntax on our server and have been planning > the > database according to our website's content needs. We've been > struggling to > understand the best way to customise the software and would really > appreciate some help. Attached is a word document containing a table > that > outlines our plan so far for the database tables, indicating the > fields of > each datatype, and our basic database fields as well. > > The first column - Database fields is the fields of the database. The > second > column - Fieldtype is the type of content that field will contain. The > third > column - Event DataType Field and other columns with '+' or 'x' in > indicate > whether that database field is relevant for each of the datatypes. The > Event > Datatype Field Description column and Music DB field description, > etc indicate what that database field is used for in each datatype. > > I understand that Syntax works best is for there to be a minimum > number of > fields in the database by repurposing fields that are used for a > specific > purpose in one datatype (Eg, the Events datatype), for use in another > datatype (Eg, the Music datatype). That occurs for DB field Date3 in > the > attached document - the fields are called different names in the > different > datatypes. > > So basically I have tried to have the least number of DB fields by > repurposing the fields used by the different datatypes in other > datatypes to > some extent but am finding it a real mental exercise. > > Would anyone mind taking a look at the document and checking out the DB > fields in the left hand side column labelled "MUSIC and EVENTS", and > the > items labelled "PEOPLE, PLACES, and ORGANISATIONS", and see if you can > see > which if any of the fields can be re-purposed between these two groups > of > datatypes? Or if anyone can offer a better strategy for this > normaization > process that would be fantastic. I also understand that Syntax needs > datatypes to have identical field types for this to work. > > All of this seems very difficult to do quickly, and our project's > deadline > is very soon. I'm guessing we could just set up the db with as many > fields > as needed by the different datatypes (even if some fields will be used > in > only one or two datatypes) and then cut out irrelevant fields > one-by-one as > we find > matches along the way. Is that correct (or do we absolutely need to > repurpose all fields among the different datatypes wherever possible > from > the very start)? > > Are we on the right track? > > Regards, > > Adrian > <DPGSyntaxDBfieldsanddatatypestable.doc> -- Sandy Smith, Senior Programmer Forum One Communications, Inc. ss...@fo... tel. 703-548-1855 x28 http://www.forumone.com/ |