Phoenix.pm: "Why Not To Use Foreign Keys" ?

[Scott Walters]

I guess there is a an emulator, Hurcules, that runs mainframe stuff.
I think it's free but I've never really looked into it. That might
help you with your C port. 

SNOBOL would be dead if Philip Budne hadn't rewritten the 360 bits
in portable C 7 years back, but now, fools like me run it ;)

-scott

On  0, Anthony Nemmer <intertwingled at qwest.net> wrote:
> 
> I'm on the Model 204 bandwagon myself. It was designed by a couple of 
> hackers from MIT Tech Square 9th floor for an agency at Fort Meade, is 
> written for the most part in IBM mainframe assembly language (accept for 
> the pattern matcher, which is written in C), was designed from the 
> get-go to perform FAST complicated queries against billion record 
> databases. Records can consist of one or more fields, multiply occurring 
> fields are allowed, there can even be records with NO fields. There are 
> also "hidden fields", where the field index is stored, but the 
> field=value pair is NOT stored. This database is non-relational. In 
> fact, it ESCHEWS relational. It's called Model 204. I worked with it for 
> six years at the Drug Enforcement Administration and it KICKS THE ASS of 
> any relational database you can name. Unfortunately, it only runs on IBM 
> mainframes or plug compatibles. =( On the other hand, it has a "User 
> Language" that has many perl-like features plus built in 3270 screen 
> control and pattern matching built into the core syntax of the language. 
> It is one of two languages that I have known that makes programming IBM 
> mainframes FUN. The other is REXX.
> 
> That's all for now.
> 
> This is Tony, Signing Off.
> 
> Scott Walters wrote:
> 
> >Well, I'm on the Postgres bandwagon myself, but most people can't design a
> >half way relationtional schema in the first place, so either their lone table
> >has no foreign keys to relate to or their quagmire has so many problems that
> >losing data is the tip of the iceberg. Continuing with the bad habit of using
> >myself as anecdotal evidence, I've cleaned up a number of bad Access database
> >*and* MySQL databases. 
> >
> >The original story of MySQL is somewhat telling though. They just needed
> >to do simple reports on vast amounts of data that chained weekly and only
> >constituted a few tables. So that's what MySQL was built for ;)
> >
> >-scott
> >
> >On  0, eden li <eden.li at asu.edu> wrote:
> >  
> >
> >>I'm surprised they still haven't implemented it.  Hell even Microsoft Access lets you do foreign keys.  The reasons they give for not implementing them are kind of bogus.  When you design a sufficiently complex schema, it's nice to be able to depend on the database to keep certain things about the schema correct.  All the problems they mention with foreign keys can be taken care of by good design.
> >>
> >>It seems the MySQL developers don't trust us with being able to make the right decisions about using foreign keys in the right places.  Maybe that's the reason I haven't touched mysql in so long...
> >>
> >>
> >>Bill Lindley wrote:
> >>    
> >>
> >>>...linked from a Slashdot thread, it's the MySQL developers eating 
> >>>humble pie... funny reading in a 'cvs commit' diff..
> >>>
> >>>much more at
> >>>http://lists.mysql.com/internals/1771 
> >>>      
> >>>
> >
> >
> >  
> >
> 
> 
> -- 
> 
> SKYKING, SKYKING, DO NOT ANSWER.
> 
>