The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Schema Awareness

I saw a reference on this site a while back (can't find it now) bemoaning the (arguably) cumbersome way database access is handled under most of the current platforms (eg. ADO and so on).

The fact that MS seems to come up with different data access API's every couple of years, and revs the others constantly, suggests this is an area that still has room for improvement.

For a start, it seems to me the C# (for example) compiler should have an intrinsic awareness of the schema of the DB it relies on, which should lead to things like compile-time SQL validation.

Beyond that it seems to me that the whole notion of data access is so core to ALL business applications, that any language that targets business should have data access built into its core, and not relegated to some external API's...
Greg Tomkins Send private email
Tuesday, September 07, 2004
 
 
Well, I think a LOT of the DotNet APIs were writen with DB access in mind.  I think including it in the core language though is excessive, because there are times when your application is just doing something simple not requiring a database. Why make that part of the core application. Now, compile time validation of SQL queries is a very interesting idea. My first thought was that its bad, because what if my DB is on another machine and i don't have net access.  Theres been plenty of times when I just write and compile a bunch of code when i'm at the coffee shop or somewhere without DB access, and i'll just test it all later. So, it'd have to be an option. Also, how detailed of validation should it be?  It can't actually run the queries, I guess it could just see if the tablenames/fieldnames matched up OK.
Vince
Tuesday, September 07, 2004
 
 
This is rather simple to do...

Two years ago, I was working on a large scale database (> 200GB) that was under constant development and revision.  I wrote a simple handler that would validate an assumed (last known good) database schema and notify the developers (us) when an invalid query was attempted.

Most of the time these were generated by optimizations that happened and the change didn't propogate through our access layer, but it was *VERY* helpful to get notification of a problem and where it was.

This was all in Java and I think I have that code around somewhere...
KC Send private email
Wednesday, September 08, 2004
 
 
Oh yeah, and we had another simple app that would compare our development database with our production database to give us the diff in terms of fields, datatypes, constraints, and sequences... all in Oracle.
KC Send private email
Wednesday, September 08, 2004
 
 
Any thoughts about MS putting a CLR inside SQL Server in Yukon? I was all excited about this at first but my attempts to exercise it via the beta failed and I eventually gave up.

From the examples I saw it looked like the same basic data access model was being used (eg. ADO.NET, SqlDataAdapter etc.), which was a little disappointing to me (I was hoping for something a little simpler and more compile-time checked).

So the main benefit would be in performance (eg. not having to move data across process boundaries all the time). Hopefully I can make the beta work at some point and actually try it out...
Greg Tomkins Send private email
Wednesday, September 08, 2004
 
 
Although it will of course mean that your SQL statements can auto-complete in the IDE...

Wednesday, September 08, 2004
 
 
My boss is excited about it because he wants us to write all of our code in Yukon modules and distribute it that was as opposed to installing asp applications.  I pointed out that "doesn't that require our clients to buy Yukon to use our apps?"

Right... they're going to be really happy with that one.

If we *really* wanted to be strategic about this, we'd port it to mySQL and do all of our deployments on that...  it would lower our overhead/licensing costs dramatically.
KC Send private email
Wednesday, September 08, 2004
 
 
Commoditize your complements -- smart.

We did this and it helped our sales.

Our policy is that the database is ONLY for data. No stored procedures, no triggers, nothing tricky that won't port trivially to another DBMS.
Joel Spolsky Send private email
Wednesday, September 08, 2004
 
 
Which is why I've been arguing for the last 2 years on this board that Stored Procs just arn't worth it.  The small added benifit of speed is negated by the fact that it destroys any hope of portability. On top of that, it will also be a pain if you ever need to take your query and make it more complex by adding dynamic components.
Vince
Wednesday, September 08, 2004
 
 
"Our policy is that the database is ONLY for data. No stored procedures, no triggers, nothing tricky that won't port trivially to another DBMS."

Interesting, I would have guessed the polar opposite. I am conflicted about SP's. I like your policy but I'm not sure it is realistic.

Anyway, that would be the biggest negative to the CLR Yukon thing, you'd be just that much more tied to MSSQL and Windows. But I have this feeling that that performance benefit might be irresistible (possibly this isn't a major concern in your case?), but I really have to play with it to find out for sure...
Greg Tomkins Send private email
Wednesday, September 08, 2004
 
 
"Commoditize your complements -- smart.

We did this and it helped our sales."

Thus speaketh Joel.

I'd love to make things completely portable, but right now, it's all a mess of spaghetti code, so I'm doing cleanup as I go.

When I took this position, they had a Score of *2*.  I've managed to push us up to a *5* in nine months, but it's been a struggle to move programmers when "things work for now."

Arg.

When I was working on the project I described above (large scale databases), we ported from Oracle 8i to mySQL and it took exactly one week to make *all* the changes for 100% compatibility between the two.
KC Send private email
Wednesday, September 08, 2004
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz