Neil Schemenauer wrote:

>On Tue, Jan 07, 2003 at 05:37:33PM +0100, Juan David Ib??ez Palomar wrote:
>
>
>>Typically you build interfaces that show different views of
>>the same data, for example, "show all the members of a group"
>>(1) and "show all the groups a member belongs to" (2). In this
>>example, without a query language there are three solutions:
>>
>>1. The group object has a list with all the users that belong
>>   to it; then the first view is simple but the second one is
>>   complex.
>>
>>2. The user object has a list with all the groups it belongs to;
>>   then the second view is simple but the first view is complex.
>>
>>3. The group has the list of users and the user has the list of
>>   groups. Then both views become simple, but data is duplicated
>>   and you have to keep it in sync, making changes becomes
>>   complex and error prone.
>>
>>
>
>If you need to do both operations often then 3 is the best solution.
>Keeping the data consistent is a matter of providing an interface to
>manipulate it.  That's just good programming.
>
>
>

But what happens if you reach production and you need
to add a new view? Then, if you want something efficient,
you have to change the data structure and to transform
the existing data to the new model.

In real world applications (which are complex, where the
needs change continuously, often the client don't knows
what he wants and you have very scare resources) just
good programming is not enough, you also need good
development practices and any tool that helps is
welcomed. If a catalog and a query language helps, then
use it (and it really helps).


>Also, which do you think is faster: accessing a list attribute that is
>most likely already in memory, or doing a join on tables that could have
>a large number of rows?
>
>
>

That's the point. Doing a join of tables is fast enough most
of the time, and it is more simple. So you use it until performance
becomes a problem, then you optimize and build your own data
structures.

Using your own data structures since the beginning just because
they are faster is the typical problem of optimizing before you
need it, what only raises development costs.


>Writing an application with ZODB is similar to writing an application
>with no database.  Ask yourself what data structures you would use in
>order to be efficient if the data was not persistent.  Usually it's a
>small step from there to decide how and where persistent data should be
>connected to the DB root.
>
>
>

And what happens if I don't have the time to ask myself
what data structures are the most effecient? I know data
structures and algorithms are more funny than building
HTML interfaces, but I have to reduce the development
time and I can't remove the HTML interfaces. All I can
do is to remove the data structures I don't really need.


Regards,

--
J. David Ibáñez, http://www.j-david.net
Software Engineer / Ingénieur Logiciel / Ingeniero de Software