comp.databases.theory  
Author Message
swdev1





PostPosted: 2003-8-28 8:27:14 Top

mysql, comp.databases.theory Morten - did you ever see my response to your post about E-R ???
lemme know.
mondo regards [Bill]



 
swdev1





PostPosted: 2003-8-28 21:45:00 Top

mysql >> comp.databases.theory Morten - ah - good - at least you saw my response.
One thing you will want to wrap your head around is table-driven definitions
of any E R relationship.
Once you get that - I sense the light bulb will come on and you will stop
muttering into your beer.
as is - outta the box - mySql does not have the things you are looking for.
My earlier suggestion to change your tool set was a valid one - if mySql
ain't doing it for you I'd suggest you switch to postgreSql - where you can
easily implement everything you've mentioned.
The thing that blows my mind here with your concept of E-E-R is that you are
trying to take a domain of features, and apply it to a dbm that does not
have those features. My original question, as I remember - was - what is
driving your selection? Domain or vendor? If domain, you need to change
your vendor. If vendor - you'd better be ready to do some coding with mySql
to implement the things your want.

I know my comments could have been taken as annoying - but if you missed the
point about 'choosing' then I'd say go out for another beer. I'm an
advocate of using what works given a particular domain or business problem
to solve - so if you are choosing a domain first - then you have chosen the
wrong toolset - the E-E-R stuff you want ain't there - and you are in for a
long haul of coding to implement most of it - and still you won't get there
directly. If I've saved you some time with my opinion, great. If I've made
you mad to the point where you want to code it up anyway - thats great too.
My entire point, which I hope you do understand - is that 'You can't get
there from here, as it exists today' .

I don't want a flame war with you, of course. I hit the wall with mySql a
few years back, and figured out how to code around its dbms limitations to
make contraints and triggers, but thats ONLY from a client/server
programming standpoint - and its a lot o code already. To go in and do
class/subclass would be the most tedious thing you can code for - I still
strongly suggest you change your toolset to something else.


mondo regards [Bill]

 
Morten.Gulbrandsen





PostPosted: 2003-9-3 20:56:00 Top

mysql >> comp.databases.theory Morten - ah - good - at least you saw my response.

<Morten>
I saw it, I have read it several times.
I have hoped to get more comments.
</Morten>

To go in and do class/subclass would be the most tedious
thing you can code for - I still
strongly suggest you change your toolset to something else.


<Morten>
If this is true,
for all current stable and unstable available versions of MySQL,
I think one alternative is
PostgreSQL (free SQL database system, very close to the SQL standard)

http://www.postgresql.org/
By all respect for MySQL:

could someone comment on this please ?

My statement is
1) no commercial RDBMS is supporting all
codds 12 requirements,
2) only knowledge in ER theory from Chen is insufficient.

Yours Sincerely

Morten Gulbrandsen
</Morten>



mondo regards [Bill]
William Sanders / Electronic Filing Group Remove the DOT BOB to reply via
email.
FREE LONG DISTANCE -> mailto:email***@***.com
mySql / VFP / MS-SQL
"Morten Gulbrandsen" <email***@***.com> wrote in message
news:email***@***.com...
> "swdev1" <email***@***.com> wrote in message news:<C%b3b.406$email***@***.com>...
> > Morten - did you ever see my response to your post about E-R ???
>
>
> dear SWDEV 1
> Yes I did,
>
> but I wasn't sure if you wanted to help or annoy !
>
> <swdev1>
> I like mySql a lot, btw - but all of the things you've described are
> available in other databases [not mySql].
> </swdev1>
>
>
>
> The way I'd like to go is quite general,
> 1.) from a given software specification
> Enhanced Entity relationship diagram,
> which is something quite different from
> classical E-R diagrams,
>
> including class / subclass relationships,
> inheritance, generalization
> category
[snip]