If I have 2 million rows in a db4o database, would you recommend a large flat table, or a hierarchy? -

i have 2 million rows in flat db4o table. lot of information repeated - example, first column has 3 possible strings.

i break table 4-tier hierarchy (i.e. navigate root >> symbol >> date >> final table) - worth speed , software maintenance point of view?

if turns out cleaner break table hierarchy, recommendations on method achieve within current db4o framework?

answers questions

to answer question, need more information. kind of information store?

i'm storing objects containing strings , doubles. hierarchy exactly, in concept, file system directories, sub-directories, , sub-sub-directories: single root node contains array of subclasses, , each sub-class in turn contains further arrays of sub-sub-classes, etc. here example of code:

// rootnode---| //            sub-node 1----| //                          |-----sub-sub-node 1 //                          |-----sub-sub-node 2 //                          |-----sub-sub-node 3 //                          |-----sub-sub-node x (others, n elements) //            sub-node 2----| //                          |-----sub-sub-node 1 //                          |-----sub-sub-node 2 //                          |-----sub-sub-node 3 //                          |-----sub-sub-node x (others, n elements) //            sub-node 3----| //                          |-----sub-sub-node 1 //                          |-----sub-sub-node 2 //                          |-----sub-sub-node 3 //                          |-----sub-sub-node x (others, n elements) //            sub-node x (others, n elements) class rootnode {   ilist<subnode> subnodecollection = new list<subnode>();   string rootnodeparam; } class subnode {   ilist<subsubnode> subsubnodecollection = new list<subsubnode>();   string subnodeparam; } class subsubnode {   string subsubnodeparam; }  // now, have work out way create query filters  // rootnodeparam, subnodeparam , subsubnodeparam. 

ans access-patterns of data? reading single objects query / search. or reading lot of objects related each other?.

i'm trying navigate down tree, filtering parameters go.

in general db4o (and other object databases) @ navigational access. means first query objects, , there navigate related objects. example first query user-object. there navigate users home, city, job, friends etc objects. kind of access works in great in db4o.

this i'm trying do, , works in db4o if have 1-1 mappings between classes , subclasses. if have 1-to-many implementing arraylist of classes within class, can't query without instantiating whole tree - or misled on one?

so in example in case 4-tier hierarchy can work great db4o, when can navigate root symbol object , on. mean root object has collection of 'children'-object

yes - there way query, if each subnode contains collection?

as sam stainsby pointed out in commend, db4o doesn't have notion of tables. stored objects , thats db4o's unit of storage. don't try think in terms of tables, doesn't work db4o.

as said, repeat information, thats candidate separated in other objects, can referenced other objects. in general first design domain-model, aware of how data organized , related each other. , think kind of data-access-patterns have. , try find out how can design classes/object in way works db4o.

to answer question, need more information. kind of information store? ans access-patterns of data? reading single objects query / search. or reading lot of objects related each other?.

in general db4o (and other object databases) @ navigational access. means first query objects, , there navigate related objects. example first query user-object. there navigate users home, city, job, friends etc objects. kind of access works in great in db4o.

so in example in case 4-tier hierarchy can work great db4o, when can navigate root symbol object , on. mean root object has collection of 'children'-object

btw: if feel more natural think in terms of tables data, recommend using relational database. relations databases awesome @ dealing tables.