►Q◄ Best ways to break a large DB table???

[pureist]

was there any indication of how straight forward it would be to introduce such functionality?
it would definitely be a worthwhile user sponsored enhancement.
..along with nested If's
..along with being able to have process buttons on forms of new instances

After verifying with support, we can't resolve Object name at runtime to get from an attribute. This really kills a great design and idea I had to keep the code clean.

[BenHayat]

was there any indication of how straight forward it would be to introduce such functionality?
it would definitely be a worthwhile user sponsored enhancement.
..along with nested If's
..along with being able to have process buttons on forms of new instances

After verifying with support, we can't resolve Object name at runtime to get from an attribute. This really kills a great design and idea I had to keep the code clean.

The answer was that, there is no way to do it in Aware. When I think about it, there are so many places in IDE that the tool references object's and it's attributes and forms at design time and introducing runtime resolution of object, can create a mess in the tool.

After discussing my whole case with Support, based on "my" situation, my original approach is correct, but the implementation will not be not clean and will get grow in size. I have to think outside of the box with a clever idea how to skin this cat.

[BenHayat]

..along with nested If's

This reminds me when I was finishing my Masters, I had to take two courses on writing Compilers. For these two course we had to write a miniature Pascal compiler written in Pascal or Algol (our choice) on Univac 1108. One of the most challenging part was to be able implement parsing nested ifs and produce the final code to be assembled.

Many don't realize, Aware had to write a full language parser to understand our code. Most of the configurator tools in the market don't have a language that you can code in, where we have in our rule language. I greatly appreciated Aware because I know how complex this part is.

[RocketRod]

Further explanation.

I would pursue my original concept. It doesn't matter how few attributes you have in the master table but it's important that you at least put the industry there. Also to retain a master table simplifies your coding a lot. To the user they don't see any issues say in creating an item as you would use a process.

Create master with master.industry = users industry
Edit master

You then have just one Edit form for the master with each industry having its own form section based on applicability of the mater category. The industry form section displays the information as a form as these reference attributes would not have multiple ticked on for the reference. Yes the count of the master table would be large but it would be small in size.

This enables you to write one query, one add, one edit rather than a set for each industry.

I'm not sure why you require a m-2-m middle table? Maybe you could elaborate as I would just see subscriptions as another reference for the mater table?

Cheers Rod

[BenHayat]

Further explanation.

I would pursue my original concept. It doesn't matter how few attributes you have in the master table but it's important that you at least put the industry there. Also to retain a master table simplifies your coding a lot. To the user they don't see any issues say in creating an item as you would use a process.

Create master with master.industry = users industry
Edit master

You then have just one Edit form for the master with each industry having its own form section based on applicability of the mater category. The industry form section displays the information as a form as these reference attributes would not have multiple ticked on for the reference. Yes the count of the master table would be large but it would be small in size.

This enables you to write one query, one add, one edit rather than a set for each industry.

I'm not sure why you require a m-2-m middle table? Maybe you could elaborate as I would just see subscriptions as another reference for the mater table?

Cheers Rod

Thanks Rod;
I need to think through the cases since each item for each industry becomes a child of a single master record for each vendor, rather than an standalone record in the it's own industry table under the vendor. Every time I need to deal with a record I first have to bring it's single parent master record into context and then fetch all it children.

For example, to create MasterBO
LoggedInUser.Industry = 'Aviation'
LoogedInUser.MasterBO.Industry=LoggedInUser.Industry

Then anytime I need to create a new AviationBO, I first have to bring it's parent into context by finding it and then assign the parent to child.
AviationBO.Parent=MasterBO

But from this point, anytime I need to find any AviationBO, I have to have to find the master for that user and then find an individual child.

Thinking out loud...

Then this raises the question, if I only have ONE masterBO per user (since a user only has ONE industry), why do I even need a MasterBO? I can make the user as the masterBO and all AviationBO hangs from a user and not a middleman, like MasterBO.

I hate middleman, they always get in your way.

[ACDC]

Breaking it down, meaning I keep all the "restaurant" category in one table, Automobile items in another table, rather than putting them all in one table and then logically break it down by having a category field in there.

I always go with breaking what could be a single object into many objects and then use the power of "Object Groups "when referencing and creating rules on the object . This lets me have rules specific to each object and rules common to each object providing more order and understanding in the big scheme of things. When creating a rule on the object and referencing the Object Group, all the objects get updated in the group with the rule. So it's very easy to maintain the group setup. Also I think it's more efficient this way

I mention this because its very easy to forget the powerful Object Grouping feature at design time

[BenHayat]

Breaking it down, meaning I keep all the "restaurant" category in one table, Automobile items in another table, rather than putting them all in one table and then logically break it down by having a category field in there.

I always go with breaking what could be a single object into many objects and then use the power of "Object Groups "when referencing and creating rules on the object . This lets me have rules specific to each object and rules common to each object providing more order and understanding in the big scheme of things. When creating a rule on the object and referencing the Object Group, all the objects get updated in the group with the rule. So it's very easy to maintain the group setup. Also I think it's more efficient this way

I mention this because its very easy to forget the powerful Object Grouping feature at design time

I'm leaning towards this direction due to the power of Object grouping.
Thanks!

[RocketRod]

Yes I use groups a lot too and that would work for you too.

It would be nice if Support could add functionality so that you could specify the group member BO when creating a record. In the example the string IndustryCode defines the Group member BO that is to be added.

ENTER NEW MEMBER LoggedInRegularUser.IndustryCode OF IndustryGroup

Cheers Rod