Stupid Database Questions

[Jonathan Randall]

i've been working with databases for like 2 years and I have NEVER heard of any of whatever you listed. we use SQL SERVER 2000, Oracle, mySql, Sybase, MS Access. we ususally write database scripts which include all the commands, queries, the tables, constraints, relationships, foreign and primary keys and so on. I do have a great MS SQL Server 2000 tutorial that I can email you maybe just PM me your email address if you want to take a look at it.

Thanks, but I'm not up to learning a new database - even if it is modern. You make me feel old! LOL :>).The PC magazines were full of these programs in my day... and the Internet was a curiosity for those who could afford 1200 baud modems.

 

[OUMoose]

Thanks, but I'm not up to learning a new database - even if it is modern. You make me feel old! LOL :>).The PC magazines were full of these programs in my day... and the Internet was a curiosity for those who could afford 1200 baud modems.

That's it. Bob, can we put up an old BBS? Have to dial in to it even. This newfangled technology is spoiling everyone!

 

[FearlessFreep]

Borland is still in business but I think they underwent a name change awhile ago, to something like Inprise, but then I think they changed back. They still make a C++ compiler but their biggest claim to fame these days is probably Delphi, a version of ObjectPascal with some RAD tools. I used it maybe three years ago in wrapping a Windows based UI around some Python command-line programs that did bioinformatics analysis

 

[FearlessFreep]

these are object-oriented programming languages, not object-oriented "databases".
This means you can store the database functions, stored procedures and relationships in classes where you can instantiate throughout your code.
You can inherit from them, you can override stored procedures, polymorphism, interfaces!
do you know how cool that is?

Not quite. Smalltalk is an OO Langauage, but GemStone is/was an OO database that was actually, at the time I was using it, specifically for Smalltalk. GemStone later came out with a Java version. There were a few others like ObjectStore and Versant I believe, that were OODBMS designed for specific languages, but I never had chance to use them much. I *did* use GemStone, though, and it was a blast. Very powerful and a lot easier to use as an application progreammer than an RDBMS.

One problem I'm not sure if anyone got resolved properly was that different languages like Smalltalk, Java, C++, etc...have different object models so building an OODBMS that could be used by clients written in different languages was a bit tricky. I'll admit I haven't used an OODBMS for several years now so I'm not really up on the state of the art.

 

[DavidCC]

OODBMS is already passing away, largely unadopted. it is being replaced by persistence engines (for example Hibernate) that reside in JVM's and provide object persistence, not only DBMS-neutral but DBMS-invisible! You just instantiate your class, pass the key value to the constructor, and it handles all of the data retrieval. Same for saving changes to the object, full support for 2-phase commits etc completely hidden from the application developer.

 

[FearlessFreep]

Actually, David, you just described GemStone circa early 90s, except it used a Smalltalk VM rather than a Java VM.

 

[Bigshadow]

OODBMS is already passing away, largely unadopted. it is being replaced by persistence engines (for example Hibernate) that reside in JVM's and provide object persistence, not only DBMS-neutral but DBMS-invisible! You just instantiate your class, pass the key value to the constructor, and it handles all of the data retrieval. Same for saving changes to the object, full support for 2-phase commits etc completely hidden from the application developer.

I haven't used these systems yet. I don't use Java very often. We are a Microsoft shop and I work almost entirely with .NET and SQL2000 (Now). Not to mention I have spent a great dealing of time as a Database analyst as well as software developer, so I have no problems in dealing with SQL Server.

As for those systems, I like it and sort of don't like it. It is sort of like the black box approach. Personally, I like to be able to open the black box and know how it works

Systems like these are underpinned by a DBMS, correct? They have to commit that data to something less volatile than memory, especially when dealing with transactions. So I am assuming there is a database underneath just there is a middle teir that does all the IO with the database and provides an object interface to the developer. I have written .NET components that do similar to that (application specific) as well as DLLs.

I really like to write middle teir code. Lots of fun!