architecture question: not representing inheritance in the data model

First up, I know I'll get some good answers here, but in general, are there
any newsgroups devoted to overall application architecture?
Second, sorry for cross-posting but in this case I think it's appropriate, I
want to hear answers from both sides.
Instead of representing inheritance in the data model, in the particular
project I'm working on now I've decided to do it in OO to keep it looser;
each class gets its own table, because the details vary, but implements an
interface. Each class serves a static collection of itself which it loads
from the database. I get a master list of these items by putting all the
collections together into one of the common interface type.
Obtaining a master list in this way is a great simplification over the route
I would have normally chosen - I otherwise would have had a "base" table
containing the properties of the common interface, and requiring that all
"inheritor" tables have a foreign key to it. I already know that this is a
little iffy since 1 to 1 relationships aren't exactly a good thing. Of
course, I could have thrown everything into one table containing all the
fields in every class, which poses its own problems and ugliness. Not liking
either of these options, I decided to dump representing inheritance at all
in the database. And this led me in a new direction...
Partially through the convenience of generics, I've noticed that since I'm
caching everything locally already, it's easy to just do dictionary lookups
through all this data to find subsets. I'm in effect sidestepping the normal
chore of setting up stored procedures. Actually, I use attributes to specify
table names and fields to populate in each class, so I have no pre-written
SQL at all in the entire application. I sort of like it, but this is
something new for me - I normally push a lot of stuff as far as I can down
into the data model; now I'm just using the database as a "dumb" container.
So to those other architects out there, what is your take on this approach?
Thanks,
Paul
P.S. - some additional information
1. yes, in this case, the user will often need access to all the data at
once since there will be several different global analysis views
2. the data will change only wly through an automated processPJ6 wrote:
> First up, I know I'll get some good answers here, but in general, are ther
e
> any newsgroups devoted to overall application architecture?
Not that I know of, but don't let that stop you. I've snipped your post
but it sounded mostly sound. I just thought you might find this page
(and the whole site it's on in fact) interesting. It's sometimes useful
to be reminded that generally nothing we do in software development
requires new or original thought :)
<http://www.agiledata.org/essays/mappingObjects.html>
Larry Lard
Replies to group please

Anyone using Excel 2007 as client ?

Overall pretty cool, but apparently you can't select a single level of a dimension in the pivot table.

For instance, I have level Year, Quarter, Month, Week, Day.

Having to look at last week's sales per day, I'd be selecting a specific week and I'd have the Day level only as row labels.

This worked in Excel 2003, but I can't figure out how to leave out the Year, Q, M and Week levels.

In the PivotTable Field List, you have a check box next to the Time dimension, but nothing next to each level in the dimension. So you have to have all levels of the dimension in the rows of the pivot.

This means a lot of useless drillthrough for the users as they go down from Year to Quarter to Month to Week to Days.

Am I missing something ?

In Excel 2007 you can display the Day level only by 'hiding' the other levels. If you drill down to the lowest level day, right click on any item | Show/Hide Fields | Uncheck the Year level - the year level is hidden. Repeat for the other levels you want to hide.

Hope this helps!

|||

Thanks Zaheera it does help, that's what I needed.

I think this is a feature that needs improvement, since I need 17 clicks before I have drilled down to Days, and then removed the levels one by one.

|||

To accomplish this in fewer clicks - you can right click on an item in the highest level | Expand/Collapse | Expand to <lowest level>. In one-click you've drilled down to the lowest level. Now you'll need to hide each level one by one as described above (which can be a pain - I agree). Or you can do this in one-step in VBA (Alt + F11 to open the editor, Cntrl + G to go to the immediate window): Activecell.PivotField.CubeField.HiddenLevels = 3 and the top 3 levels will be hidden at once.