Could this be a badly disguised jab at the good burgers from Sybase, who offer their flagship product, slightly restricted, under the name Adaptive Server Enterprise Express Edition (cough) (Link takes you to the registration form) since almost a year?
In my opinion Oracle is one of the least trustworthy software vendors and I sure as hell wouldn't bank my company on them, regardless of the price they ask.
They can't get new cars easily because the closest nation won't trade with them and for the longest time neither would most of the Western World.
Uhh, and on what fact exactly are you basing this statement on, except on talking out of your arse?
I don't think that "most of the Western World" actually gave a flying fig about a badly botched CIA operation, which still seems to embarass and infuriate a lot of Americans up to this day.
Always nice to be blasted by someone who doesn't have a clue how much work it is to support a file format with a 700 page spec sheet that references another 1000 pages of SVG specifications and assorted documentation.
Yes, the filter is an import filter right now, and, yes, we will add an export filter as well. Have you written a filter today?
I don't think it's a good idea to publicly chastise potential customers for raising a very valid point.
Martin, congrats on getting so highly moderated on/. for what is essentially a marketing post. Seriously, I mean it. It's no easy feat, plus you actually have a very valid point in the discussion.
So you may consider this to be constructive criticism:
It always sort of gets my hemerrhoids itching when I see an European purveyor charge their fellow Europeans significantly more then their world wide bretheren. I can see this model working on a currency fluctuation band of +/- 10%, but this isn't the case for a rather long time, between the EUR and the USD.
Thus the product would be essentially discualified for purchase by me, since I don't like feeling ripped off. I could imagine that a lot of potential European customers feel the same.
You may want to take that up with your marketing guys.
Sure, there may be areas where Microsoft's native Office formats have some advantages
I really don't intend to be the prissy poster here. But what areas may that exactly be?
Except of course that is if you're talking about a full out, totally committed Microsoft shop only. And I don't think that the public at large should see it that way.
[...] that will finish Vista years late and without most of its promised key features[...]
Well, according to the well reputed, German C't mag features like digital restrictions throtteling functionality and stuff like secure video path (or whatever they call it this week) will work just fine.
Should give you, that's the general consumer, some pause to think about where Microsofts priorities are.
What flaw? By now, nearly everyone should know that things in pockets are very prone to getting scratched, just by observing their cell phones.
I cary a Nokia 9300 around which, granted, is most of the time loosely in my bag and sometimes in my pocket.
I carried a Nokia 6230 around for a year mostly in my front pocket (keys and all). Both of them displays look, while not pristine, quite acceptable. Thank you very much.
I suggest that you find yourself a different cell phone manufacturer if the displays of your phones (which are a rather crucial component) are scarred so badly after day to day use.
10% of your customers will take up 90% of your time.
I did support on a customer site for a database vendor and had a lot of interaction with their local support organization.
The worst about those 10% are that they are usually dweebs, that bought 60$ worth of ODBC drivers and believe they have a life long right to pester you. This is despite the fact that they never coughed up for a support contract.
On the other hand. Companies with partially huge and critical installations, who pay for alliance support contracts hundreds of thousands of $ are usually pretty much realists. They expect good support and they expect that you look at their issues in depth . But they usually don't expect a turnaround with the correct solution within a couple hours.
Of course, if production is down then all bets are off (alas the vendor will usually do whatever it takes to get the site back up).
You know, I was really impressed by this article and her presentation until a friend, who is media purchaser for a large domestic chain made me aware that the new Courtney Love was shipped with copy protection.
That was in Europe and maybe a couple years ago.
Even though she might not be personally responsible for that gaffe I couldn't quite get the word hypocrite out of my head.
Thinking about it, you're right. I may receive the occasional landline call, but it's mostly from somebody who has my cell #.
The problem however that I run a very small business. You have to advertise your presence and a mobile number (as well as a mail address like SuperDuperConsult@hotmail.com, or an URL, like http://www.VeryCheapHosting.com/~SuperDuperConsult/4711 .html) leaves an impression of being just a slight bit dodgy.
The problem was resolved by screening out anonymous calls at the switch. For some reason those creeps don't like to identify themselves.
Thanks; teaches me once again that it's always worth it to listen to different point of views.
Coming from the enterprise world of software integration, per seat licensing for database engines can be a major cost factor. And if you don't need the totally hardcore huge database- , thousands of transactions per second -, warehousing -, or advanced replication features of a database engine then Postgresql is a very viable contender in terms of cost effectiveness.
MS SQL Server is rarely used in such environments, since it's Windows only, and even though you can run serious iron under Windows today, those shops usually run Unix -, IBM -, or even VMS-boxes. Either traditionally, or due to the fact that specific features just don't cut it under Windows (i.e. clustering under TruUnix).
5. MySQL's supposed gotchas pale in to comparison to Oracle's.
I always figured Oracle to be a badly assorted mass of a lot of files preferrably scattered around on a lot of disks. I think the architecture is a mess and that installation, administration and tuning is like a root canal while you get all four wisdom teeth extracted at the same time without narcosis. But...
If you have a look at this list of MySQL idiosyncrasies you will see why MySQL is simply unusable in an enterprise environment, or even in an environment that relies on the validity of your database transactions.
That doesn't mean that MySQL doesn't have a legit place, but it's certainly not in the billing environment of a major Telco, or in any billing environment for that matter.
...why increase the risk of your development process by switching back and forth? Oracle is available under a free development license.
Maybe so that his customers have a choice between an awfully expensive database engine, coming with awfully expensive support or a free alternative (which may also come with expensive support).
If the app can really be adapted that easily I think the guy or his company would be stupid not to offer such an option to customers who can't afford awfully expensive DBAs
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.
Jeeeez, there are so many comments that provoke a me too comment in this thread, but I so wholeheartedly agree and I'm a TDP (total database person).
SQL was never designed to produce procedural code. The whole idea of the damn language is that you work in sets. You provide the information what you want, from where you want it and how to get it and then you can go to the pub for a couple o' pints of lager, while your query cranks away for the next 16 hours or so. It was never intended to loop through 3 million customer rows in order to set a flag if said customers should be annoyed by your newest marketing campaign or not.
Thus came the cursor and you know instandly that the application sucks shit and that the programmers had no fucking clue about dealing with databases if you find an excess of them in an application (yes! this includes some of those fine and very expensive ERP applications, at least from a DB perspective). I have seen really awful and dreadful shit out there.
Mind you. I don't think that stuff like stored procedures, triggers and even cursors are a bad thing. Being a dogmatist is never good and all of those objects have their use (yes, even cursors:). But what a lot of people seem not to understand is that a database is not your complete , integrated application environment. As a matter of fact all design tools, which are too database centric (Uniface, anyone?) I have ever seen are just gawddamnawful.
I would say that you should place code into the database only when that code reduces the amount of data that must be moved to the application by at least and order of magnitude
I'd wager that anything regarding data consistency should be part of the database and not the application. This usually doesn't require a big deal of programming logic in the database and can be handled just fine implicitely (data type, unique indexes), by triggers, or via declarative constraints.
I don't dispute your reasoning and in fact think you're quite right, but have seen instances where it really mad a whole lot of sense to export big chunks of the application logic to the database (stored procedures) or to connected Open Servers, which feed the databases (ok, this could be the order of magnitudes:).
The specific application I have in mind (and worked for) cranks out 15'000'000 bookings (that's not row mofifications) on an average day and the folks who designed it are some of the smartest I ever met in the industry.
They are aware of the costs however. Essentially this application is very, very hard to port to another database if it's not outright impossible.
In addition this is certainly not an approach you want to take as an ISV.
There are very, very good reasons why you would not want to use GUIs to manage databases in an enterprise environment.
Even discounting the CliqueClique risk (Are you sure you want to drop the ExtremelyCriticalCompanyGoesBustWhenWeLoseItDb database? [YES] [NO]) only scripts and a serious approach to version controlling them can give you the necessary tools to rebuild your databases in a reasonable amount of time when a desaster kicks in.
Yeah I know, there is the "reverse engineering" option in a lot of GUIs. Using this as your desaster prevention measure, is about as reliable as a backup concept, which mandates the storage of unlabeled floppy disks in shoe boxes somewhere in the attic.
There is certainly a place for GUIs within a database context. For example they can be very useful to look up stuff. For schema changes however - and we're talking of an enterprise environment here - I would very strongly discourage their use.
You could also use the server-side cursor and scroll forward without sending that info to the client.
[Disclaimer: I worked for 10 years with Sybase SQL Server and - ASE, which have the same origin as MS SQL Server. Things may be very different now, so apologies if I talk out of my arse]
If cursor handling is still such a performance hog on MS SQL Server as it is in Sybase ASE I would prefer to avoid this. Granted, it's certainly faster then trying to hack something via temporary tables or "SET ROWCOUNT" and delete. Nevertheless Cursors are a bad idea one Sybase ASE and I suspect on MS SQL Server too.
As are two phase commits by the way (or where at least until DTM), but I'm digressing here.
and have obviously not the slightest clue regarding basic data management concepts. You talk out of your arse without the hint of even a fart of knowledge on the subject:
While that can be annoying, to be sure, why do people rely on the database to do their data validation?
Uh, so you really want to rely on some sweat shop programmers in Kuala Lumpur to get all your validation straight? You're really sure that the consultant that came in for a week to fix a legacy Cobol program understood all idiosyncrasies and properties of your corporate data? You guarantee - putting your job, professional reputation and career on the line - that no brain dead clerk in accounting hacks together an Access "application", which corrupts your database? See, I thought not.
That should be done in the application code long before you ever run an insert or update.
No, it sure as hell should not. As a matter of fact it's probably virtually impossible to guarantee that you caught any and all mistakes in the application. The complexity goes up exponentientally with the complexity and age of the application. I've interviewed a significant amount of applicants for dba jobs. If any of them would have come up with such a braindead concept the interview would have been concluded at once. There would be no more need to continue.
If you're trying to insert invlaid data, you're the only one to blame.
You ever heard of data type properties, unique indexes, declarative constraints, triggers and stored procedures? Either not, or you seem a bit unclear on the concept. Those are exactly the objects that support you in guaranteeing that this really cheaply produced piece of software as well as the illicite front ends from the accounting department rumaging through your corporate data are prevented on the lowest possible level to corrupt your data. Sure, it can still happen, the database engine can have bugs, you can have fundamentally flawed logic in your database code, etc. But the feasibilty for this to happening is exponentiality larger when you rely on the application to guarantee correct data.
I suggest that you educate yourself before turning yourself into the laughing stock of millions of readers.
Slashdot Mirror
I'd wager an "insightful", had I mod-points...
Actually I was thinking more around the lines that the executives in charge oughta be tarred, feathered and carried out of town on a piece of rail.
The wild west really starts to look good.
With articles popping up in the New York Times, The Washington Post or the Globe and Mail Sony should have just about lost any trust with the public.
If I'd be their (stunningly inefficient and stupid) spokesflack I'd be searching now for a pack of razor blades or a plastic bag.
What a bunch of losers...
In my opinion Oracle is one of the least trustworthy software vendors and I sure as hell wouldn't bank my company on them, regardless of the price they ask.
Uhh, and on what fact exactly are you basing this statement on, except on talking out of your arse?
I don't think that "most of the Western World" actually gave a flying fig about a badly botched CIA operation, which still seems to embarass and infuriate a lot of Americans up to this day.
LSD was invented 60 years ago by Professor Albert Hofman, who will celebrate his 100th birthday come January.
Yes, the filter is an import filter right now, and, yes, we will add an export filter as well. Have you written a filter today?
I don't think it's a good idea to publicly chastise potential customers for raising a very valid point.
So you may consider this to be constructive criticism:
It always sort of gets my hemerrhoids itching when I see an European purveyor charge their fellow Europeans significantly more then their world wide bretheren. I can see this model working on a currency fluctuation band of +/- 10%, but this isn't the case for a rather long time, between the EUR and the USD.
Thus the product would be essentially discualified for purchase by me, since I don't like feeling ripped off. I could imagine that a lot of potential European customers feel the same.
You may want to take that up with your marketing guys.
I really don't intend to be the prissy poster here. But what areas may that exactly be?
Except of course that is if you're talking about a full out, totally committed Microsoft shop only. And I don't think that the public at large should see it that way.
Well, according to the well reputed, German C't mag features like digital restrictions throtteling functionality and stuff like secure video path (or whatever they call it this week) will work just fine.
Should give you, that's the general consumer, some pause to think about where Microsofts priorities are.
I cary a Nokia 9300 around which, granted, is most of the time loosely in my bag and sometimes in my pocket.
I carried a Nokia 6230 around for a year mostly in my front pocket (keys and all). Both of them displays look, while not pristine, quite acceptable. Thank you very much.
I suggest that you find yourself a different cell phone manufacturer if the displays of your phones (which are a rather crucial component) are scarred so badly after day to day use.
HTH HAND, etc
I did support on a customer site for a database vendor and had a lot of interaction with their local support organization.
The worst about those 10% are that they are usually dweebs, that bought 60$ worth of ODBC drivers and believe they have a life long right to pester you. This is despite the fact that they never coughed up for a support contract.
On the other hand. Companies with partially huge and critical installations, who pay for alliance support contracts hundreds of thousands of $ are usually pretty much realists. They expect good support and they expect that you look at their issues in depth . But they usually don't expect a turnaround with the correct solution within a couple hours.
Of course, if production is down then all bets are off (alas the vendor will usually do whatever it takes to get the site back up).
Oracle is about the last software company having anything to do with altruism; period.
That was in Europe and maybe a couple years ago.
Even though she might not be personally responsible for that gaffe I couldn't quite get the word hypocrite out of my head.
And your proof for this assertion is?
The problem however that I run a very small business. You have to advertise your presence and a mobile number (as well as a mail address like SuperDuperConsult@hotmail.com, or an URL, like http: //www.VeryCheapHosting.com/~SuperDuperConsult/4711 .html) leaves an impression of being just a slight bit dodgy.
The problem was resolved by screening out anonymous calls at the switch. For some reason those creeps don't like to identify themselves.
Coming from the enterprise world of software integration, per seat licensing for database engines can be a major cost factor. And if you don't need the totally hardcore huge database- , thousands of transactions per second -, warehousing -, or advanced replication features of a database engine then Postgresql is a very viable contender in terms of cost effectiveness.
MS SQL Server is rarely used in such environments, since it's Windows only, and even though you can run serious iron under Windows today, those shops usually run Unix -, IBM -, or even VMS-boxes. Either traditionally, or due to the fact that specific features just don't cut it under Windows (i.e. clustering under TruUnix).
I always figured Oracle to be a badly assorted mass of a lot of files preferrably scattered around on a lot of disks. I think the architecture is a mess and that installation, administration and tuning is like a root canal while you get all four wisdom teeth extracted at the same time without narcosis. But...
If you have a look at this list of MySQL idiosyncrasies you will see why MySQL is simply unusable in an enterprise environment, or even in an environment that relies on the validity of your database transactions.
That doesn't mean that MySQL doesn't have a legit place, but it's certainly not in the billing environment of a major Telco, or in any billing environment for that matter.
Maybe so that his customers have a choice between an awfully expensive database engine, coming with awfully expensive support or a free alternative (which may also come with expensive support).
If the app can really be adapted that easily I think the guy or his company would be stupid not to offer such an option to customers who can't afford awfully expensive DBAs
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.
Jeeeez, there are so many comments that provoke a me too comment in this thread, but I so wholeheartedly agree and I'm a TDP (total database person).
SQL was never designed to produce procedural code. The whole idea of the damn language is that you work in sets. You provide the information what you want, from where you want it and how to get it and then you can go to the pub for a couple o' pints of lager, while your query cranks away for the next 16 hours or so. It was never intended to loop through 3 million customer rows in order to set a flag if said customers should be annoyed by your newest marketing campaign or not.
Thus came the cursor and you know instandly that the application sucks shit and that the programmers had no fucking clue about dealing with databases if you find an excess of them in an application (yes! this includes some of those fine and very expensive ERP applications, at least from a DB perspective). I have seen really awful and dreadful shit out there.
Mind you. I don't think that stuff like stored procedures, triggers and even cursors are a bad thing. Being a dogmatist is never good and all of those objects have their use (yes, even cursors :). But what a lot of people seem not to understand is that a database is not your complete , integrated application environment. As a matter of fact all design tools, which are too database centric (Uniface, anyone?) I have ever seen are just gawddamnawful.
So yeah: Me too I guess...
I'd wager that anything regarding data consistency should be part of the database and not the application. This usually doesn't require a big deal of programming logic in the database and can be handled just fine implicitely (data type, unique indexes), by triggers, or via declarative constraints.
I don't dispute your reasoning and in fact think you're quite right, but have seen instances where it really mad a whole lot of sense to export big chunks of the application logic to the database (stored procedures) or to connected Open Servers, which feed the databases (ok, this could be the order of magnitudes :).
The specific application I have in mind (and worked for) cranks out 15'000'000 bookings (that's not row mofifications) on an average day and the folks who designed it are some of the smartest I ever met in the industry.
They are aware of the costs however. Essentially this application is very, very hard to port to another database if it's not outright impossible.
In addition this is certainly not an approach you want to take as an ISV.
Even discounting the CliqueClique risk (Are you sure you want to drop the ExtremelyCriticalCompanyGoesBustWhenWeLoseItDb database? [YES] [NO]) only scripts and a serious approach to version controlling them can give you the necessary tools to rebuild your databases in a reasonable amount of time when a desaster kicks in.
Yeah I know, there is the "reverse engineering" option in a lot of GUIs. Using this as your desaster prevention measure, is about as reliable as a backup concept, which mandates the storage of unlabeled floppy disks in shoe boxes somewhere in the attic.
There is certainly a place for GUIs within a database context. For example they can be very useful to look up stuff. For schema changes however - and we're talking of an enterprise environment here - I would very strongly discourage their use.
[Disclaimer: I worked for 10 years with Sybase SQL Server and - ASE, which have the same origin as MS SQL Server. Things may be very different now, so apologies if I talk out of my arse]
If cursor handling is still such a performance hog on MS SQL Server as it is in Sybase ASE I would prefer to avoid this. Granted, it's certainly faster then trying to hack something via temporary tables or "SET ROWCOUNT" and delete. Nevertheless Cursors are a bad idea one Sybase ASE and I suspect on MS SQL Server too.
As are two phase commits by the way (or where at least until DTM), but I'm digressing here.
Why do you perceive the TCO higher with Postgresql then with MS-SQL Server?
I'm really curious here.
While that can be annoying, to be sure, why do people rely on the database to do their data validation?
Uh, so you really want to rely on some sweat shop programmers in Kuala Lumpur to get all your validation straight? You're really sure that the consultant that came in for a week to fix a legacy Cobol program understood all idiosyncrasies and properties of your corporate data? You guarantee - putting your job, professional reputation and career on the line - that no brain dead clerk in accounting hacks together an Access "application", which corrupts your database? See, I thought not.
That should be done in the application code long before you ever run an insert or update.
No, it sure as hell should not. As a matter of fact it's probably virtually impossible to guarantee that you caught any and all mistakes in the application. The complexity goes up exponentientally with the complexity and age of the application. I've interviewed a significant amount of applicants for dba jobs. If any of them would have come up with such a braindead concept the interview would have been concluded at once. There would be no more need to continue.
If you're trying to insert invlaid data, you're the only one to blame.
You ever heard of data type properties, unique indexes, declarative constraints, triggers and stored procedures? Either not, or you seem a bit unclear on the concept. Those are exactly the objects that support you in guaranteeing that this really cheaply produced piece of software as well as the illicite front ends from the accounting department rumaging through your corporate data are prevented on the lowest possible level to corrupt your data. Sure, it can still happen, the database engine can have bugs, you can have fundamentally flawed logic in your database code, etc. But the feasibilty for this to happening is exponentiality larger when you rely on the application to guarantee correct data.
I suggest that you educate yourself before turning yourself into the laughing stock of millions of readers.
HTH HAND