 | |
#431
 
| |||
| |||
|
Re: Object oriented database -
11-05-2008
, 07:09 PM
|
On Nov 4, 8:17 am, mrto... (AT) tpg (DOT) com.au wrote: This was more response than I actually thought I my post would get (first time posting to newsgroups) :-). I do apologise if my post falls outside the scope of this group as I might have been looking for a more pragmatic discussion, although the theory interests me. My first objective is to create something that fits within the framework of existing programming languages, making it as easy as possible for programmers to use. As I see it, there is enough in common between C++, Java and C# for example to be able to create a common object model. Seeing from some posts I might have used the term "object model" wrongly, but I have defined it as the set of classes used by one application. I am not looking to create a "data warehouse" style database that would be used by a wide range of applications, but rather a database / distribution system that is tightly linked with one or just a few applications. The reasoning being that there are a lot of applications that need to store complex data that doesn't have much meaning outside the application itself. From experience, I have seen so many applications that use a relation database just because that happens to be the only or the easiest available choice. If you're going to make Finite State Machines (i.e. objects) persist then I recommend you at least consider the following barriers: * The difficulty of allowing schema evolution of persistent FSMs * The need for finding consistent cuts when persisting FSMs * The contradictory nature of transactions and orthogonal persistence Persisting values instead of FSMs is /much/ easier. |
RDBMSs. Sometimes your data is easily expressed as tables and
relations, but OODBs also see uses when the relational model does not
apply as much. I would love to have some of the databases services
available independent of the relational model when I felt it was an
appropriate thing to do, and most RDBMs's would probably be able to
fufill these purposes, its just that it would be extra work to use the
relational model in some cases.
What I actually have ended up doing in a few cases typically some
homegrown solution to avoid RDBMs's added expense and effort but to
get some of the transaction logging and recovery just by sheer
homegrown coding. What we need are some more transaction oriented
systems with better programming support rather than just always with
the RDBMs stuff.
Lets face it, right now the premier RDBMS environment is SQL. This is
sort of a sad state of affairs folks, this is in no way or form a
modern language with scoping, code reuse, or any other sort of
endearing quality. While many commercial and open source databases
bring in more modern language support in some areas, we're essentially
saddled with SQL's flat and sad namespace and at least in my case,
ducktyped anonymous column naming just to get the same sort of
flexibility any decent pick system gives you by default.
RDBMS purists tend to always want the relational algebra, without
considering that some folk sometimes just might want regular
arithmetic instead.
#432
| |||
| |||
|
|
On Nov 4, 8:17 am, mrto... (AT) tpg (DOT) com.au wrote: This was more response than I actually thought I my post would get (first time posting to newsgroups) :-). I do apologise if my post falls outside the scope of this group as I might have been looking for a more pragmatic discussion, although the theory interests me. My first objective is to create something that fits within the framework of existing programming languages, making it as easy as possible for programmers to use. As I see it, there is enough in common between C++, Java and C# for example to be able to create a common object model. Seeing from some posts I might have used the term "object model" wrongly, but I have defined it as the set of classes used by one application. I am not looking to create a "data warehouse" style database that would be used by a wide range of applications, but rather a database / distribution system that is tightly linked with one or just a few applications. The reasoning being that there are a lot of applications that need to store complex data that doesn't have much meaning outside the application itself. From experience, I have seen so many applications that use a relation database just because that happens to be the only or the easiest available choice. If you're going to make Finite State Machines (i.e. objects) persist then I recommend you at least consider the following barriers: * The difficulty of allowing schema evolution of persistent FSMs * The need for finding consistent cuts when persisting FSMs * The contradictory nature of transactions and orthogonal persistence Persisting values instead of FSMs is /much/ easier. |
RDBMSs. Sometimes your data is easily expressed as tables and
relations, but OODBs also see uses when the relational model does not
apply as much. I would love to have some of the databases services
available independent of the relational model when I felt it was an
appropriate thing to do, and most RDBMs's would probably be able to
fufill these purposes, its just that it would be extra work to use the
relational model in some cases.
What I actually have ended up doing in a few cases typically some
homegrown solution to avoid RDBMs's added expense and effort but to
get some of the transaction logging and recovery just by sheer
homegrown coding. What we need are some more transaction oriented
systems with better programming support rather than just always with
the RDBMs stuff.
Lets face it, right now the premier RDBMS environment is SQL. This is
sort of a sad state of affairs folks, this is in no way or form a
modern language with scoping, code reuse, or any other sort of
endearing quality. While many commercial and open source databases
bring in more modern language support in some areas, we're essentially
saddled with SQL's flat and sad namespace and at least in my case,
ducktyped anonymous column naming just to get the same sort of
flexibility any decent pick system gives you by default.
RDBMS purists tend to always want the relational algebra, without
considering that some folk sometimes just might want regular
arithmetic instead.
#433
| |||
| |||
|
|
On Nov 4, 8:17 am, mrto... (AT) tpg (DOT) com.au wrote: This was more response than I actually thought I my post would get (first time posting to newsgroups) :-). I do apologise if my post falls outside the scope of this group as I might have been looking for a more pragmatic discussion, although the theory interests me. My first objective is to create something that fits within the framework of existing programming languages, making it as easy as possible for programmers to use. As I see it, there is enough in common between C++, Java and C# for example to be able to create a common object model. Seeing from some posts I might have used the term "object model" wrongly, but I have defined it as the set of classes used by one application. I am not looking to create a "data warehouse" style database that would be used by a wide range of applications, but rather a database / distribution system that is tightly linked with one or just a few applications. The reasoning being that there are a lot of applications that need to store complex data that doesn't have much meaning outside the application itself. From experience, I have seen so many applications that use a relation database just because that happens to be the only or the easiest available choice. If you're going to make Finite State Machines (i.e. objects) persist then I recommend you at least consider the following barriers: * The difficulty of allowing schema evolution of persistent FSMs * The need for finding consistent cuts when persisting FSMs * The contradictory nature of transactions and orthogonal persistence Persisting values instead of FSMs is /much/ easier. |
RDBMSs. Sometimes your data is easily expressed as tables and
relations, but OODBs also see uses when the relational model does not
apply as much. I would love to have some of the databases services
available independent of the relational model when I felt it was an
appropriate thing to do, and most RDBMs's would probably be able to
fufill these purposes, its just that it would be extra work to use the
relational model in some cases.
What I actually have ended up doing in a few cases typically some
homegrown solution to avoid RDBMs's added expense and effort but to
get some of the transaction logging and recovery just by sheer
homegrown coding. What we need are some more transaction oriented
systems with better programming support rather than just always with
the RDBMs stuff.
Lets face it, right now the premier RDBMS environment is SQL. This is
sort of a sad state of affairs folks, this is in no way or form a
modern language with scoping, code reuse, or any other sort of
endearing quality. While many commercial and open source databases
bring in more modern language support in some areas, we're essentially
saddled with SQL's flat and sad namespace and at least in my case,
ducktyped anonymous column naming just to get the same sort of
flexibility any decent pick system gives you by default.
RDBMS purists tend to always want the relational algebra, without
considering that some folk sometimes just might want regular
arithmetic instead.
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.