Hi Calven, In single table inheritance, you can share table column for multiple sub entity, for example, you may have a total on only 30 different columns required to map your 75 attributes if you go strictly and only share column for attributes with the same name. To save columns, you may create some columns with generic names for each required types and map the table column to more specific attribute names.
Single table inheritance is the easiest one to use and always works as expected. The only downside is the default SQL does not create the non null constrains on the database, you may add them be creating custom SQL check. If you want more flexible data storage and be able to add new activities without new java classes, you can also create so sort of meta activity to describe an activity attributes and rules and store the attributes values in a child table like this one: ActivityAttributeValue id activityID attributeID numericValue stringValue dateValue ... The attribute define the type of the value to store and use. Regards, Samuel > Le 22 juin 2016 à 11:33, Calven Eggert <cal...@mac.com> a écrit : > > Hi all, > > My question is not simply a WO question, however, perhaps the WO experts have > a best practice way of doing this in WOnder. > > I've been asked to design an application that tracks a process that a patient > goes through, with the following: > > 1. Each patient will follow one of many different paths. > 2. Each path consists of a number of activities and the order of the > activities along that path. > 3. At the moment there are 3 different paths and 15 different kinds of > activities. Each activity has different fields to store in the database. > (Approx. 5 fields per activity X 15 activities = 75 fields) > > It would be great if the application could be designed so that new > paths/activities can be created by the user in an administration section, as > opposed to having the developer create new versions of the application each > time a new path/activity needs to be created. Right now, I'm prepared to > soldier through and simply design it so that there is 1 table for each > activity. I've looked at creating a generic table that has many string > fields and then storing the field type, etc, however, this seems like way too > much work (validation, etc.). Also thought about one activity table but 75 > fields sounds unmanageable plus the fact that there will be more activities > added in the next year. > > Anyone else out there have a different solution or idea? > > Calven > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com > > This email sent to sam...@samkar.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
