value by default 0

> Yes, there is no foreign key constraints in the database. My
> Object-Relationnal mapping take care of this.
> So for MySql, it's just a attribute with not null constraint.

Ugh. You do understand this means you can have invalid
data in your database?

Use constraint on your database, it's the right thing to do.


--
Martijn Tonies
Database Workbench - development tool for MySQL, and more!
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com

All the constraints are defined in the object model and only the object
framework access the database.
Should not have any problem.

Pierre

"Martijn Tonies" <m.tonies@upscene.removethis.com> a écrit dans le message
de news: 47695aa5$0$2010$e4fe514c@dreader17.news.xs4all.nl. ..
>
>> Yes, there is no foreign key constraints in the database. My
>> Object-Relationnal mapping take care of this.
>> So for MySql, it's just a attribute with not null constraint.
>
> Ugh. You do understand this means you can have invalid
> data in your database?
>
> Use constraint on your database, it's the right thing to do.
>
>
> --
> Martijn Tonies
> Database Workbench - development tool for MySQL, and more!
> Upscene Productions
> http://www.upscene.com
> My thoughts:
> http://blog.upscene.com/martijn/
> Database development questions? Check the forum!
> http://www.databasedevelopmentforum.com
>
>

On Wed, 19 Dec 2007 22:09:57 +0100, Pierre Gilquin wrote:
> All the constraints are defined in the object model and only the object
> framework access the database.
> Should not have any problem.

You have a great deal more confidence that the object model will be used
in perpetuity than I do. As I see it, so long as the data is stored in a
RDBMS, eventually someone will want and need to access the data outside
the bounds of your model. And once they are reading your data by other
means (such as running plain SQL against it, or a report-generating tool
of some kind), they will realize that they can also maintain the data
using plain SQL. If you build your authentication into the RDBMS, then
SQL will not be able to bypass your authentication rules. If you build
your constraints into the RDBMS, then it will be harder to bypass those.
One of the big reasons to build stored procedures instead of coding
business rules into applications is than then they are available to the
external RDBMS tools and toys as well, and the business rules and logic
are updated in a single step.

--
95. My dungeon will have its own qualified medical staff complete with
bodyguards. That way if a prisoner becomes sick and his cellmate tells the
guard it's an emergency, the guard will fetch a trauma team instead of
opening up the cell for a look. --Peter Anspach's Evil Overlord List

> All the constraints are defined in the object model and only the object
> framework access the database.
> Should not have any problem.

Should not <> will not.

I repeat:

> > Use constraint on your database, it's the right thing to do.

If you disagree, I suggest you do some reading up on why you're
actually using a (R)DBMS instead of flat files :-)

--
Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle &
MS SQL Server
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com

this is probably not the place for this discussion.

But your approach is Database centric. My system is object oriented and the
database is just for object's persistence purpose only.

Pierre

"Martijn Tonies" <m.tonies@upscene.removethis.com> a écrit dans le message
de news: 476a2a76$0$1308$e4fe514c@dreader20.news.xs4all.nl. ..
>
>> All the constraints are defined in the object model and only the object
>> framework access the database.
>> Should not have any problem.
>
> Should not <> will not.
>
> I repeat:
>
>> > Use constraint on your database, it's the right thing to do.
>
> If you disagree, I suggest you do some reading up on why you're
> actually using a (R)DBMS instead of flat files :-)
>
> --
> Martijn Tonies
> Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle
> &
> MS SQL Server
> Upscene Productions
> http://www.upscene.com
> My thoughts:
> http://blog.upscene.com/martijn/
> Database development questions? Check the forum!
> http://www.databasedevelopmentforum.com
>
>

> this is probably not the place for this discussion.
>
> But your approach is Database centric. My system is object oriented and
the
> database is just for object's persistence purpose only.

Wrong.

My approach is aimed at taking proper care of data on the lowest
level possible in your system.

This is nothing but common sense. Read Peter H Coffins post, he
explains it in more detail.

What happens if your object oriented system has faulty logic? You
can get invalid data.

What happens if "something" happens outside your program code?
You can get invalid data.

Solving this at the DBMS level is the best way to go. This, however,
does not mean you shouldn't have decent code in place in your object
oriented system in order to get some meaningfull error messages to
the user and so on, nevertheless, get those checks into place!

It's the right thing to do.

--
Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle &
MS SQL Server
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com

Martijn ,

I just can agree on one think :
The model of an application must be in only one place but not in a mix of
both. That was the origin of my problem.
Your model is build from tables of a database and that's ok.
My model is a graph of objects and then all fonctionnalities and constaints
must be implemented at that level.
This allows me to change the persistence (from Oracle to MySql or even a
flat files or XML file) without effort.
I change my database from Oracle to mysql and I get this problem because I
forget (or loose it) to set a constraint in the object model.
Then the database was in charge and they have different behavior !
In theory a persistence is not even required but in the real world, I have
to recreate the last graph after a crash or maintenance.
In this model, there is no concept of primary and foreign key as they are
part of the actual persistence system used. It's the job of the ORM
(Object-relationnal mapping) to take care of the underlying persistence
system.
Of course, I am aware that nothing else than the ORM must access directly
the database/files.


It's not that you intend to suggest but you help me to have clearer view on
this matter.


Pierre





"Martijn Tonies" <m.tonies@upscene.removethis.com> a écrit dans le message
de news: 476a483c$0$26918$e4fe514c@dreader27.news.xs4all.nl ...
>
>> this is probably not the place for this discussion.
>>
>> But your approach is Database centric. My system is object oriented and
> the
>> database is just for object's persistence purpose only.
>
> Wrong.
>
> My approach is aimed at taking proper care of data on the lowest
> level possible in your system.
>
> This is nothing but common sense. Read Peter H Coffins post, he
> explains it in more detail.
>
> What happens if your object oriented system has faulty logic? You
> can get invalid data.
>
> What happens if "something" happens outside your program code?
> You can get invalid data.
>
> Solving this at the DBMS level is the best way to go. This, however,
> does not mean you shouldn't have decent code in place in your object
> oriented system in order to get some meaningfull error messages to
> the user and so on, nevertheless, get those checks into place!
>
> It's the right thing to do.
>
> --
> Martijn Tonies
> Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle
> &
> MS SQL Server
> Upscene Productions
> http://www.upscene.com
> My thoughts:
> http://blog.upscene.com/martijn/
> Database development questions? Check the forum!
> http://www.databasedevelopmentforum.com
>
>

Hello Pierre,

> I just can agree on one think :
> The model of an application must be in only one place but not in a mix of
> both. That was the origin of my problem.
> Your model is build from tables of a database and that's ok.

This is not my view at all. My programming model has nothing to do
with the fact that I always put constraints in place on the database level.
I've designed systems with an object approach and designed tables
afterwards BUT the tables are normalized so that no data gets duplicated
or becomes invalid due to programming errors. This includes constraints
on the database level separated from your object model.

> My model is a graph of objects and then all fonctionnalities and
constaints
> must be implemented at that level.

Of course, this is perfectly valid and the same as with my projects. Your
constraints and functionality is available in your programming language,
object oriented, PHP scripting, whatever.

> This allows me to change the persistence (from Oracle to MySql or even a
> flat files or XML file) without effort.

This has nothing to do with database constraints!

> I change my database from Oracle to mysql and I get this problem because I
> forget (or loose it) to set a constraint in the object model.

See above, your constraints need to be in place in your object model, this
is correct and makes sense.

> Then the database was in charge and they have different behavior !
> In theory a persistence is not even required but in the real world, I have
> to recreate the last graph after a crash or maintenance.
> In this model, there is no concept of primary and foreign key as they are
> part of the actual persistence system used. It's the job of the ORM
> (Object-relationnal mapping) to take care of the underlying persistence
> system.
> Of course, I am aware that nothing else than the ORM must access directly
> the database/files.

Which may-be beyond your control AND of course, the point about the
failed constraints or bugs still stand.

> It's not that you intend to suggest but you help me to have clearer view
on
> this matter.

I agree with your constraints approach in your object model, this is
of course perfectly normal and required for your model to work
properly.

However, the data is the most imporant part of any application or set of
application that actually needs to store data. This is why you should put
constraints on the database level as well. It avoids invalid data despite
programming errors, external/3rd party applications accessing your data,
other programmers working on your object model etc...


--
Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle &
MS SQL Server
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com

On Thu, 20 Dec 2007 11:48:10 +0100, Martijn Tonies wrote:
> This is nothing but common sense. Read Peter H Coffins post, he
> explains it in more detail.

I do try...

Some day, there'll be a mechanism to grant authorities to stored
procedures instead of users, and life will really get fun. The long
goal of being able to actually enforce things like "only User_X can
delete rows with 'User_X' in column user_id" by granting DELETE to the
procedure and taking it away from all users, forcing deletes through the
SP, will actually be achievable. We can kinda do it with triggers but
it's very messy.

--
15. I will never employ any device with a digital countdown. If I find that
such a device is absolutely unavoidable, I will set it to activate when
the counter reaches 117 and the hero is just putting his plan into action.
--Peter Anspach's list of things to do as an Evil Overlord

> Some day, there'll be a mechanism to grant authorities to stored
> procedures instead of users, and life will really get fun. The long
> goal of being able to actually enforce things like "only User_X can
> delete rows with 'User_X' in column user_id" by granting DELETE to the
> procedure and taking it away from all users, forcing deletes through the
> SP, will actually be achievable. We can kinda do it with triggers but
> it's very messy.

Other DBMSses, like Firebird, already have such grants. And yes, it
allows you to control a lot.


--
Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle &
MS SQL Server
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com