[kplato] Fwd: Re: [kproject] Planning and Analysis 101

[Anders Johansson]

No, I agree we need a data model. I just think it's better to define it in 
terms of data types, structures and classes. Not data bases.

My thought is that there are people out there who may be using this system in 
the future, who aren't using RDBMS, but ODMBS, or perhaps one of the 
classical systems even (VSAM, anyone? :) If we define an API with data types, 
we can add a back end later for external databases, embedded databases or 
text files if that's your fancy. Defining a relational model (isn't 
normalization only used in relational models?) can be done in the API, 
without tying it to a specific implementation like xBase.

Anders

On Monday 18 June 2001 23:52, Jim Sabatke wrote:
> 1.    Thanks for the definition!
>
> 2.    I'm not sure that we can seperate the data model from the
> functionality discussion.  The data model needs to fit the functionality
> we decide on.
>
> Jim
>
> Anders Johansson wrote:
> >DTD is an XML term: Document Type Definition. It describes the contents of
> > an XML document to the interpreter
> >
> >Also, may I suggest that we confine ourselves to defining the database
> > API, and leave the details until later.
> >
> >Regards
> >Anders
> >
> >On Monday 18 June 2001 23:30, Jim Sabatke wrote:
> >>Regarding the CVS discussion.  I have never used CVS and I'll bet a lot
> >>of the other manager types haven't either.  That said, the text left me
> >>confused.  However, I have a general knowledge about what CVS does, and
> >>I definately think we should use it.
> >>
> >>Regarding the relational database model,  I think most of the discussion
> >>has been to not use an RDBMS, but rather something like XBase.  Of
> >>course the XBase tables could/should be normalized as much as possible
> >>and not hurt performance.  Does anyone have any suggestions/preferences
> >>for documenting the database?
> >>
> >>Also, I'm ignorant as to what a "DTD" is.  We should probably define
> >>acronymns at least once.  I may have been guilty of causing this kind of
> >>confusion too.  When in doubt, ask.
> >>
> >>Jim
> >
> >_______________________________________________
> >kplato mailing list
> >kplato@master.kde.org
> >http://master.kde.org/mailman/listinfo/kplato