I'll remember that the next time my daughter turns in an assignment she completed with Open Office and output to Power Point format. Ya see, she was pissed at me at first because she didn't realize OO.o is set by default to it's own format...
That's a heartwarming story, but it doesn't turn a closed proprietory format into an open standard. Sorry.
You can call my definition incorrect, but my incorrect definition is allowing me interoperability.
Your incorrect definition doesn't allow you to do anything except to try and cloud the issue. The interoperability here is the result of hard work
by the OOo developers. Reverse engineering proprietory formats can be tricky.
What is your definition doing for you?
Fostering clear and accurate communication. You should try it sometime.
LNUX is the stock code for VA Software. They have
a lot of open source based ventures, including
the Open Source Technology Group who host
sourceforge.net and a little known discussion
board that goes by the name of Slashdot.
It may look like an attempt to compare Linux and MS, but that's just because VA (presumably) thought it'd be cool to have LNUX as their
code on all the stock exchange boards,
probably to relect the amount of FLOSS
related work they do.
How can you create an open standard when pattents are designed to prevent the use of key design aspects in open projects?
Well, we've seen proposals for patent encumbered standards rejected by some governing bodies before now. That's a good thing, and as awareness of the problem increases, I think we can expect to see it happen more and more.
It doesn't help against submarine patents, but really, it is the patents that are unrealistic here and not the idea of open standards. It just means we have two separate problems to address: 1) open standards; 2) patents.
There should be a kind of coherency between political decisions (suggested by lobbies), and reality...
That sounds to me like no one should be allowed to enact any law that wasn't already on the statue books. Or maybe you just mean that policy should only be used to rubber stamp existing practice? I can think of problems, either way...
Which is surprising, because the very point of the Linux design is that different distributions were supposed to be able to explore completely different tracks. There shouldn't be any "one distro to rule them all", yet many of the respondants demanded exactly that! (Amusingly, they couldn't agree on *which* distro to rule them all.)
It's a known issue with homo sapiens.
The species likes to organise itself into tribal
units. When social structures form around
lifestyle choices and the tribal instinct can express itself as brand loyalty or religous fervour.
this doesn't mean that the strangths claimed for linux don't exist - just the the people in the discussion are only human.
There's no reason for this OS bigotry.
I quite agree. I've even known people get evangelical about the Java Runtime Environment.
Go figure, huh?:D
Q. What's the difference between a proprietary format that everyone uses and an 'open' standard that very few people use?
A. The open standard is useless.
That's like saying that if I own a car that I drive but rarely, the car has no function. Just because a thing is underutilised, that does not mean is it without use.
Q. What do you call a proprietary format that is well understood and widely used by the computer-using community and which is unencumbered by fees or intellectual property claims?
A. I call it an 'open' standard.
Bill Gates, Steve Ballmer... and you must be the third one. Another mystery solved.
My turn to play:
Q: What do you call a definition that only three people use?
And it sounds great. I plan to buy one for myself this weekend... the nano sounded as good as any other iPod, and is packed with plenty of audio power... it was able to belt out the new Fountains of Wayne rocker, "Maureen,"...
And now a word not from our sponsors:
bollocks
Thank you for your kind attention, we now return you to your regularly scheduled astroturf.
Fair enough. I just remember seeing a post somewhere that said the accleration features worked under nv for the older cards; it's only the medium to new ones that need the closed source drivers. Apparently.
Of course, the poster in question might have had no idea what he was talking about, but no one was queueing up to toast him either. Mind you, this wasn't on/.
It also doesn't mean that you mightn't have a card that's new enough to need to binaries, but old enough to break, I suppose.
The thing that's pissing me off about nvidia is the wavy-line-kernel-ooops than crashes my machine every fourth time or so when I quit X, or switch to a console from an X session. nv doesn't have the problem, but then nv doesn't accellerate the controller that causes the problem for me either, so I can sympathise
You've got mad superscience, lots of cool shots absed on perspective and scale, giant ants, (relatively speaking, anyway) and... um...
I suppose the problem here is that Ant-Man, never had any real arch-nemesis or classic plots. For spidey you can say "we'll do the Green Goblin, work in some of the death of Gwen Stacy stuff. Maybe do Doc Ock for the sequel". That's harder to pick out for Ant-Man.
On the other hand, if you consider it as a Hank Pym movie then you get Ultron, the whole twisted oedipus complex that goes with him, possibly the Vision and Jocasta, as well as the chance to turn the CGI the other way and do some Giant-Man/Goliath stuff as well.
It could be cool. It all depends on what age range they target. If it turns into "Honey I shrunk the kids" in spandex...
But if they're financing these things theselves then that reduces the chance that they'll have such descisions forced upon them by the film backers.
Of course, that still leaves the board at Marvel to worry about... mutter mutter... peter david... mutter grumble... hulk... mutter grumble grouse
The point is, there are a lot of higher primate behaviours we do not condone in society. Alpha male behaviour in gorllias is no more a justificiation for Ballmer's temper tantrum than baboon social patterns would justify infanticide.
If you think Ballmer is a jerk and you have no problem with that, fair enough. Just don't try and say it's ok "because gorillas do it".
How about fixing the patent system instead, and getting rid of the brain-dead software patent examiners who have no clue what's "obvious to someone in the field" or not?
Well...
Because it will always be in the interests of large corporations to try and abuse the system. And they have more resources to expend on corrupting it than we do on defending it.
Because companies like Microsoft can spam the patent office to death, whatever the workforce and however knowledgeable. Raising cost of patents will not cure this, it will simply ensure that the poor inventor, the one the system allegedly is there to protect, cannot afford to enter, and that only big corporations will possess patents.
Because there is evidence to show that patents do not stimulate economic growth. Rather that they chill innovation and expansion but preserve the status quo, making it easier for established companies to preserve their profit margin without effort, and to lock out newcomers who might otherwise compete.
Even if the system were to be reformed tomorrow, the vast body of patents that have been already granted remain problematical. To examine all of them to see if they should be overturned or not would be a herculean task, exacerbated by legal challenges and delaying tactics.
As applied to software: they ain't needed to turn a profit, they don't protect the small inventor as their supporters claim, and they provide a mechanism for large corporations to neutralise the legitimate IP of small enterprises and single developers. They don't work, they're not needed and they're bad.
the 1-click purchase, is actually an example of a good patent.
In some cases they are not easy to work with but you should be able to get around all these issues.
For example in PostgreSQL, you have to define update/insert/delete rules. Sometimes these can be tricky...
mmm... that's what I mean. If the views get too complex then maintaining them may become more expensive than writing a comparatively simple interface app. Views appear to offer a generic plug-in solution, but as you say, it isn't always that simple.
I think the problem is that updatable views are a kludge. They don't work in terms of the relational model, and that's why they throw up such problems. I think they are fundamentally the wrong approach, but I'm realist enough to use them if they save me a lot of work. But it'd have to be a fairly specialised set of circumstances...
With updateable views, you can separate the physical data storage mechanism from the way it is presented to the application.
mmm... but updatable views are problematic on a number of levels. For one thing, they don't work reliably, since you can't update a derived value, for instance. And theroretically they're a mess, since you should be updating a transient derived relation that strictly speaking ceases to exist before you even issue the update.
I'm not sure I'd want users inputting data into a data warehouse via the same view that they use to access the data anyway. There's too much derived and summarised data kicking around for my liking.
It does sound a cool way to present a read-only interface though.
Oh, I'm sure there's plenty of drafts written, just none that RMS and company are ready to share.
Well, as far as I'm concerned, they can take all the time they need to get it right. It's an important work:)
Maybe, but maybe not. If nothing else, it's not 100% clear to me who the licence affects when it's based on copyright. Namely, does it apply to the person offering the copy, or the person receiving it?
The person originating the work holds the copyight - the right to copy - the work alone. He may then sell, assign or grant licences for others to also copy the work. A bit more too it than that, but that's be essentials. Permission to run a GPLed program is expressly granted in the licence, irrespective. So even SCO can use GPL software at the moment - they just can't legally distribute it. Since you can't run a program without receiving a copy in some form, we can probably safely assume that this too is included.
If GPL v3 takes aim at DRM and patents, it may restrict you from receiving a copy.
Well, yes, if Stallman chooses to change certain fundamentals of how the GPL works. I can't see why since it would conflict with the Free Software ethos, and he's been known to be quite keen on that aspect of things.
Seems unlikely though... I'm pretty sure copyright focuses on the person offering the copy.
The copyright remains vested in the author. The terms of the licence which permits use of the software could be changed to exclude, say, patent holders, but I can't see it happening.
But if it does, we'll have a whole year to change the terms under which we offer our software and/or tell Richard not to be such a twat, according to preference.
Stallman will write a draft version of the new GPL by December, after which it will be evaluated by thousands of organizations, software developers and software users in 2006.
So it doesn't look like we need panic just yet. The draft isn't yet written, and there's going to be plenty of time to offer feedback once that happens.
The whole idea of free software is that it gives people the freedom to do what they want with it. The new license will be saying something like: "Hey, you can have this candy as long as you don't take any from those guys"
hmmm... this is from the current version of the GPL:
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
So if they keep to the same formula, patents and DRM may deprive you of the rights to distribute GPL3 software, but probably not to use it.
Still, I agree there are concerns. The whole "tax the internet to pay artists" sceheme needs a lot details working out before I'll agree to that. Greive only said "could" and not should though, so I'm tempted to the conclusion that he's being quoted out of context.
But I expect a lot of the programs licenced under GLP2 "or any later licence" may end up thinking carefully about those words if GPL3 does look to go too far off the deep end.
True enough if you're working in a strongly distributed environment. Not always the case though - a lot of in-house commercial database applications use a central application server on the same platform as the DBMS and networked thin clients for the workstations. If you don't need the distriution, it's an architecture with a lot to recommend it.
I any case, I didn't say "stored procedures are useless". I said "I've can't recall needing any feature found in Oracle that is absent from PostgreSQL. Stored procedures, triggers and constraints are all part of the PostgreSQL feature set.
I did say I preferred to keep the logic in the application code where possible, and I'll stand by that; but not at the cost of making more work for myself. Old School I may be, inflexible I ain't.
Of course, the question then becomes how do you decide where to draw that line between logic that should live in a SP and logic that belongs in an application function. Within broad limits, I think there's quite a bit of room for stylistic variation.
Ah, Referential Integrity! I thought the RI was a typo for DI meaning Data Integrity. It's not a term I'm used to seeing abbreviated.
Yeah, for referential integrity I'd always use the database constraints where possible.
Equally, SQL is better for manipulating sets of data than procedural code. It is faster, and more flexible. I prefer to have the DBMS return the single dataset I want, rather than a collection that I stitch together.
Now if you said relational algebra, I'd agree. Sadly there are fairly few proper relational DBMS around - Dataphor looks interesting, and I wrote my own solution for the poblem for my dissertation a few years back. SQL on the other hand...
SQL is broken in a lot of ways. The biggest problem is that it handles bags rather than sets. There are others, such as the use of NULLs. It's not a universally held opinion, but Chris Date and Hugh Darwen have voiced such views, so I'm not really going out on a limb here.
Practically, large joins can be ferociously expensive, and denormalising is not a sensible solution (now, this is IMHO). I've generally found I can get a lot better performance by reading some tables into memory and doing sorting and filtering programatically. It's a while since I had a big enough query to make it worth while chopping up, so maybe DBMSs have improved of late. Even so there are still some queries that can't be sanely done in SQL, if only because SQL expressions don't nest properly.
That ass-u-me's that everything will always go through your app server, which is not always a given
Ah, but we were talking about apps. And sometimes you will want database access to be mediated by your own software. It adds an extra layer of security for one thing
IMO it limits you even more than putting code in the database, because now you can't ever use software that you can't make to work with your application layer.
More accurate to say that allowing that software access will entail some overhead. Of course, there's no reason not to allow some access via shared procedures, and thereby allow other software to access some functionality. Stored procedures are a useful part of the toolkit. I just don't believe in using screwdrivers as hammers.
Actually that's a perfect example of what I mean by one man's feature being another man's bloat. More marketing led design from Redmond, I can only assume.
Your RDBMS is there to do three things:
1) Store data
2) Maintain data (i.e. triggers, check constraints, etc)
3) Present your data (views, possible some stored procedures, etc).
I've never been entirely convinced by item three. Views are occasionally useful, but if you have a user interface that allows ad-hoc queries, they may be the only way to enforce data security. But if you're writing apps you may as well code the query directly. You'll need to change the code if the view changes, but apart from a few ultra-generic table based apps, that is always going to be true.
Far from it. Instead, by doing things this way, you can do a fair bit of heavy lifting in the RDBMS where appropriate, and have your application logic in the application where it belongs.
I'd agree with that. I'll occasionally break the rule for pragmatic reasons and I don't always make best use of constraints and their ilk, but I have to agree with the sentiment.
Instead, use a trigger to place an item in a queue that an external program can use to send it. This way if your transaction rolls back after the email is sent....;-)
Unless I'm misunderstading you, that cannot happen. Assuming your emailer is a little app that sits on top of the mail queue table and periodically issues "select * from...", then it never sees the queued message, because it doesn't de-cloak until the transaction commits. I think that was your point.
The best approach IMO is somewhere in the middle. I think both extremes are boneheaded.
The boneheadedness I meant lies in using programmng languages developed by database vendors. They're almost always awful.
For one thing, they tend to hold the database as being more important than the language, so you get languages where the only iteration is using cursor selects for example.
Then there is the "everything has to look like SQL and/or PL/I" syndrome, which sees table definition syntax being reused to specify parameter passing.
Finally there is the "SQL is a static, descriptive language, therefore our coding langauge must work the same way" disease, which gives us langauges with all the frustrations of coding in lisp or prolog, but without the cool stuff which makes those languages fun.
Anyway, enough with the rant. Bit of a hobbyhorse of mine, as you may have guessed:)
A bit of both, really. I do things like load static data into memory based tables to save on the overhead of joining against them. (I hate de-normalised data - it defats the point).
Otherwise, I use SQL for selects, updates, deletes and inserts, transaction handling, and a few other things like say dropping and recreating indices if I have to load a large table using insert.
I don't do much in the way of integrity consraints and cascades in SQL, and I really should make better use of such features.
Apart from that, I like to do as much as I can in C or similar.
When you say client-side... are you thinking of networked applications, or just refering to the DBMS as a server and any apps using it as clients. If it's the former case, I'd write the server to run on the database platform and keep the client apps fairly thin.
AFAIK, neither MySQL nor PostgreSQL let me alter a live database without pausing write operations to that database. If Oracle can do that, then that's a feature where it wins.
Wow. Oracle let's you change a table schema without a full table lock? It must be in there someplace or there would be data integrity errors, surely?
Slashdot Mirror
That's a heartwarming story, but it doesn't turn a closed proprietory format into an open standard. Sorry.
You can call my definition incorrect, but my incorrect definition is allowing me interoperability.
Your incorrect definition doesn't allow you to do anything except to try and cloud the issue. The interoperability here is the result of hard work by the OOo developers. Reverse engineering proprietory formats can be tricky.
What is your definition doing for you?
Fostering clear and accurate communication. You should try it sometime.
It may look like an attempt to compare Linux and MS, but that's just because VA (presumably) thought it'd be cool to have LNUX as their code on all the stock exchange boards, probably to relect the amount of FLOSS related work they do.
HTH HAND
Well, we've seen proposals for patent encumbered standards rejected by some governing bodies before now. That's a good thing, and as awareness of the problem increases, I think we can expect to see it happen more and more.
It doesn't help against submarine patents, but really, it is the patents that are unrealistic here and not the idea of open standards. It just means we have two separate problems to address: 1) open standards; 2) patents.
There should be a kind of coherency between political decisions (suggested by lobbies), and reality...
That sounds to me like no one should be allowed to enact any law that wasn't already on the statue books. Or maybe you just mean that policy should only be used to rubber stamp existing practice? I can think of problems, either way...
It's a known issue with homo sapiens. The species likes to organise itself into tribal units. When social structures form around lifestyle choices and the tribal instinct can express itself as brand loyalty or religous fervour.
this doesn't mean that the strangths claimed for linux don't exist - just the the people in the discussion are only human.
There's no reason for this OS bigotry.
I quite agree. I've even known people get evangelical about the Java Runtime Environment. Go figure, huh? :D
My turn to play:
Q: What do you call a definition that only three people use?
A: Incorrect!
Thank you. Feel free to keep talking rubbish.And now a word not from our sponsors:
bollocks
Thank you for your kind attention, we now return you to your regularly scheduled astroturf.
I had that J.C.Denton in the back of the cab, once.
That's probably what I'm thinking of then. Sounds about right now I think of it.
Of course, the poster in question might have had no idea what he was talking about, but no one was queueing up to toast him either. Mind you, this wasn't on /.
It also doesn't mean that you mightn't have a card that's new enough to need to binaries, but old enough to break, I suppose.
The thing that's pissing me off about nvidia is the wavy-line-kernel-ooops than crashes my machine every fourth time or so when I quit X, or switch to a console from an X session. nv doesn't have the problem, but then nv doesn't accellerate the controller that causes the problem for me either, so I can sympathise
Don't the old ones work with the nv driver?
And he's going to keep adding layers of XML metadata until it happens. Or hell freezes over, whichever comes first.
You've got mad superscience, lots of cool shots absed on perspective and scale, giant ants, (relatively speaking, anyway) and... um...
I suppose the problem here is that Ant-Man, never had any real arch-nemesis or classic plots. For spidey you can say "we'll do the Green Goblin, work in some of the death of Gwen Stacy stuff. Maybe do Doc Ock for the sequel". That's harder to pick out for Ant-Man.
On the other hand, if you consider it as a Hank Pym movie then you get Ultron, the whole twisted oedipus complex that goes with him, possibly the Vision and Jocasta, as well as the chance to turn the CGI the other way and do some Giant-Man/Goliath stuff as well.
It could be cool. It all depends on what age range they target. If it turns into "Honey I shrunk the kids" in spandex...
But if they're financing these things theselves then that reduces the chance that they'll have such descisions forced upon them by the film backers. Of course, that still leaves the board at Marvel to worry about... mutter mutter... peter david... mutter grumble... hulk... mutter grumble grouse
If you think Ballmer is a jerk and you have no problem with that, fair enough. Just don't try and say it's ok "because gorillas do it".
Well...
-
Because it will always be in the interests of large corporations to try and abuse the system. And they have more resources to expend on corrupting it than we do on defending it.
-
Because companies like Microsoft can spam the patent office to death, whatever the workforce and however knowledgeable. Raising cost of patents will not cure this, it will simply ensure that the poor inventor, the one the system allegedly is there to protect, cannot afford to enter, and that only big corporations will possess patents.
-
Because there is evidence to show that patents do not stimulate economic growth. Rather that they chill innovation and expansion but preserve the status quo, making it easier for established companies to preserve their profit margin without effort, and to lock out newcomers who might otherwise compete.
-
Even if the system were to be reformed tomorrow, the vast body of patents that have been already granted remain problematical. To examine all of them to see if they should be overturned or not would be a herculean task, exacerbated by legal challenges and delaying tactics.
-
As applied to software: they ain't needed to turn a profit, they don't protect the small inventor as their supporters claim, and they provide a mechanism for large corporations to neutralise the legitimate IP of small enterprises and single developers. They don't work, they're not needed and they're bad.
the 1-click purchase, is actually an example of a good patent.Ain't no such animal. For reasons, see above.
For example in PostgreSQL, you have to define update/insert/delete rules. Sometimes these can be tricky ...
mmm... that's what I mean. If the views get too complex then maintaining them may become more expensive than writing a comparatively simple interface app. Views appear to offer a generic plug-in solution, but as you say, it isn't always that simple.
I think the problem is that updatable views are a kludge. They don't work in terms of the relational model, and that's why they throw up such problems. I think they are fundamentally the wrong approach, but I'm realist enough to use them if they save me a lot of work. But it'd have to be a fairly specialised set of circumstances...
You got me. Nothing serious, anyway.
With updateable views, you can separate the physical data storage mechanism from the way it is presented to the application.
mmm... but updatable views are problematic on a number of levels. For one thing, they don't work reliably, since you can't update a derived value, for instance. And theroretically they're a mess, since you should be updating a transient derived relation that strictly speaking ceases to exist before you even issue the update.
I'm not sure I'd want users inputting data into a data warehouse via the same view that they use to access the data anyway. There's too much derived and summarised data kicking around for my liking.
It does sound a cool way to present a read-only interface though.
Well, as far as I'm concerned, they can take all the time they need to get it right. It's an important work :)
Maybe, but maybe not. If nothing else, it's not 100% clear to me who the licence affects when it's based on copyright. Namely, does it apply to the person offering the copy, or the person receiving it?
The person originating the work holds the copyight - the right to copy - the work alone. He may then sell, assign or grant licences for others to also copy the work. A bit more too it than that, but that's be essentials. Permission to run a GPLed program is expressly granted in the licence, irrespective. So even SCO can use GPL software at the moment - they just can't legally distribute it. Since you can't run a program without receiving a copy in some form, we can probably safely assume that this too is included.
If GPL v3 takes aim at DRM and patents, it may restrict you from receiving a copy.
Well, yes, if Stallman chooses to change certain fundamentals of how the GPL works. I can't see why since it would conflict with the Free Software ethos, and he's been known to be quite keen on that aspect of things.
Seems unlikely though... I'm pretty sure copyright focuses on the person offering the copy.
The copyright remains vested in the author. The terms of the licence which permits use of the software could be changed to exclude, say, patent holders, but I can't see it happening.
But if it does, we'll have a whole year to change the terms under which we offer our software and/or tell Richard not to be such a twat, according to preference.
If it happens. I don't think it will.
The whole idea of free software is that it gives people the freedom to do what they want with it. The new license will be saying something like: "Hey, you can have this candy as long as you don't take any from those guys"
hmmm... this is from the current version of the GPL:
So if they keep to the same formula, patents and DRM may deprive you of the rights to distribute GPL3 software, but probably not to use it.Still, I agree there are concerns. The whole "tax the internet to pay artists" sceheme needs a lot details working out before I'll agree to that. Greive only said "could" and not should though, so I'm tempted to the conclusion that he's being quoted out of context.
But I expect a lot of the programs licenced under GLP2 "or any later licence" may end up thinking carefully about those words if GPL3 does look to go too far off the deep end.
I any case, I didn't say "stored procedures are useless". I said "I've can't recall needing any feature found in Oracle that is absent from PostgreSQL. Stored procedures, triggers and constraints are all part of the PostgreSQL feature set.
I did say I preferred to keep the logic in the application code where possible, and I'll stand by that; but not at the cost of making more work for myself. Old School I may be, inflexible I ain't.
Of course, the question then becomes how do you decide where to draw that line between logic that should live in a SP and logic that belongs in an application function. Within broad limits, I think there's quite a bit of room for stylistic variation.
Yeah, for referential integrity I'd always use the database constraints where possible.
Equally, SQL is better for manipulating sets of data than procedural code. It is faster, and more flexible. I prefer to have the DBMS return the single dataset I want, rather than a collection that I stitch together.
Now if you said relational algebra, I'd agree. Sadly there are fairly few proper relational DBMS around - Dataphor looks interesting, and I wrote my own solution for the poblem for my dissertation a few years back. SQL on the other hand...
SQL is broken in a lot of ways. The biggest problem is that it handles bags rather than sets. There are others, such as the use of NULLs. It's not a universally held opinion, but Chris Date and Hugh Darwen have voiced such views, so I'm not really going out on a limb here.
Practically, large joins can be ferociously expensive, and denormalising is not a sensible solution (now, this is IMHO). I've generally found I can get a lot better performance by reading some tables into memory and doing sorting and filtering programatically. It's a while since I had a big enough query to make it worth while chopping up, so maybe DBMSs have improved of late. Even so there are still some queries that can't be sanely done in SQL, if only because SQL expressions don't nest properly.
Ah, but we were talking about apps. And sometimes you will want database access to be mediated by your own software. It adds an extra layer of security for one thing
IMO it limits you even more than putting code in the database, because now you can't ever use software that you can't make to work with your application layer.
More accurate to say that allowing that software access will entail some overhead. Of course, there's no reason not to allow some access via shared procedures, and thereby allow other software to access some functionality. Stored procedures are a useful part of the toolkit. I just don't believe in using screwdrivers as hammers.
Thank you, that helps a lot :)
Actually that's a perfect example of what I mean by one man's feature being another man's bloat. More marketing led design from Redmond, I can only assume.
I've never been entirely convinced by item three. Views are occasionally useful, but if you have a user interface that allows ad-hoc queries, they may be the only way to enforce data security. But if you're writing apps you may as well code the query directly. You'll need to change the code if the view changes, but apart from a few ultra-generic table based apps, that is always going to be true.
Far from it. Instead, by doing things this way, you can do a fair bit of heavy lifting in the RDBMS where appropriate, and have your application logic in the application where it belongs.
I'd agree with that. I'll occasionally break the rule for pragmatic reasons and I don't always make best use of constraints and their ilk, but I have to agree with the sentiment.
Instead, use a trigger to place an item in a queue that an external program can use to send it. This way if your transaction rolls back after the email is sent.... ;-)
Unless I'm misunderstading you, that cannot happen. Assuming your emailer is a little app that sits on top of the mail queue table and periodically issues "select * from...", then it never sees the queued message, because it doesn't de-cloak until the transaction commits. I think that was your point.
The best approach IMO is somewhere in the middle. I think both extremes are boneheaded.
The boneheadedness I meant lies in using programmng languages developed by database vendors. They're almost always awful.
For one thing, they tend to hold the database as being more important than the language, so you get languages where the only iteration is using cursor selects for example.
Then there is the "everything has to look like SQL and/or PL/I" syndrome, which sees table definition syntax being reused to specify parameter passing.
Finally there is the "SQL is a static, descriptive language, therefore our coding langauge must work the same way" disease, which gives us langauges with all the frustrations of coding in lisp or prolog, but without the cool stuff which makes those languages fun.
Anyway, enough with the rant. Bit of a hobbyhorse of mine, as you may have guessed :)
Otherwise, I use SQL for selects, updates, deletes and inserts, transaction handling, and a few other things like say dropping and recreating indices if I have to load a large table using insert.
I don't do much in the way of integrity consraints and cascades in SQL, and I really should make better use of such features.
Apart from that, I like to do as much as I can in C or similar.
When you say client-side... are you thinking of networked applications, or just refering to the DBMS as a server and any apps using it as clients. If it's the former case, I'd write the server to run on the database platform and keep the client apps fairly thin.
Wow. Oracle let's you change a table schema without a full table lock? It must be in there someplace or there would be data integrity errors, surely?
Not disagreeing, just a bit gobsmacked.