June 19, 2009 at 1:53 pm
Steve Jones - Editor (6/19/2009)
Off topic, but since we're talking slow, I saw a talk Joel Spolsky gave to Google about StackOverflow. He said they went on a C#/SS2K8 platform. He joked about search being "only SQL Server", but there was one interesting thing.He said despite the fact that he has to pay Windows licensing fees and SQL Server fees, he found that the performance of the .NET stack resulted in 10% of the hardware from open source, so the hardware difference pays for the MS stack.
Come on Steve - everyone knows it is more expensive running on the Windows stack than using Open Source. No way it could result in a cost savings...no way :w00t:
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
June 19, 2009 at 2:23 pm
Jeffrey Williams (6/19/2009)
Steve Jones - Editor (6/19/2009)
Off topic, but since we're talking slow, I saw a talk Joel Spolsky gave to Google about StackOverflow. He said they went on a C#/SS2K8 platform. He joked about search being "only SQL Server", but there was one interesting thing.He said despite the fact that he has to pay Windows licensing fees and SQL Server fees, he found that the performance of the .NET stack resulted in 10% of the hardware from open source, so the hardware difference pays for the MS stack.
Come on Steve - everyone knows it is more expensive running on the Windows stack than using Open Source. No way it could result in a cost savings...no way :w00t:
Heh... Reminds me at our city council here. About five years ago they decided to replace all those Windows clients and servers with Linux systems. They said Windows is much to expensive and Linux is free so why use Windows? After two years they admitted that they've been wrong. Of course Linux OS is free of charge but support and specialists for those systems are much more expensive than all the Windows licenses. Since now they live with Linux but they plan to go back to Windows after main costs are amortized. 😉
June 19, 2009 at 2:46 pm
I'll admit I had to back up the video and listen again. It surprised me.
You can watch it here: http://www.youtube.com/watch?v=NWHfY_lvKIQ
October 31, 2012 at 7:41 am
Yeah - the quote you will get is that they are not a tools shop. There are some other tools available, but not anywhere near the level you would expect. That is definitely one of the drawbacks I have seen. However, for managing the database they have moved everything to a web based solution which does appear to be a lot better - but I have not used it myself so I am not sure how useful it really is. The system we have is not current - in fact, it would be like running SQL 7.0.
Sadly the 2012 version is barely different from the 2008 edition which is a minor improvement over the 2005 edition...
Yes - can be very fast to build, and performance can be very good.
This is not my general experience. Opening objects has a massive overhead. The "compiled" queries can take minutes on powerful servers with as few has 20,000 objects. In addition to the randomly poor performance when you want to do anything, like sort the data, there is no query cache, so a 1 minute query will take 1 minute every time it is run even if the data is unchanged.
The Studio is about 10 years out of date compared to any tool even the most basic open source editors. It often fails to compile all dependent classes leading to hours of lost debugging. The debugger does not work at all. All error references refer to the compiled code and not the code you have written, and the web aspect (CSP) is badly bolted on to the existing framework. If it crashes there is a, 90% chance you will lose all of your unsaved code.
There is no real database monitoring system, no automated way of finding how good or bad live performance is other than customer feedback... There is no easy method of finding out what to optimise and where...
Support has been lementable for me although some of my colleges have faired a little better, I have not had a query resolved by them. When I was using one of their built in methods that was generating incorrect HTML code I queried this and their response was that as the browser error handling could cope with the rubbish code it was not an issue. This is plainly a wrong support attitude, I had to explain that I did not want to trigger querks mode and have slow and/or inconsistent browser behaviour. I have always had to do a complete rewrite using different methods wasting hours!
There is a lack of documentation. There are no books for learning (written recently). There are no best practices, coding standards etc. The available training is minimal.
All trainers have to repeat the mantra "fastest database..." at least 10 times during a training day to perhaps make the trainees actually believe it, and when you have slow performing queries they struggle to explain them...
There are 3 aspects to a good language / database / software
1. Tools
2. Documentation
3. Community
Intersystems finish bottom of the list on all of these against any other system I have worked with.
February 21, 2017 at 3:34 am
To me the rise of the ORM is an obvious indicatior for the need for object oriented databases by application developers. To share data, one must not only be able to grasp its structure, but also be able to easily explore the actual data without knowing all its nuts and bolts. This is where the relational database shines; even when its just a bunch of tables, you can query every piece of information independent of any other set of values, and you only need to combine the tables that contain data relevant to the subject of your query without even looking at the rest of the database.
It's a funny thing that a leading object database (just like many NoSQL databases) implements SQL to allow access to the underlying data. Reporting is often developed after the application is brought to life; while SQL seems obsolete during application development, for reporting there aren't so much other ways to get exactly what you (or the client) want while still keeping those reports 'decoupled' from ongoing changes in the rest of the design. It is not uncommon that application developers are unable to create proper reports and call in the help from a data analyst to solve their customers need for information, hence the need for SQL support on databases will stay for a very long time.
It would be nice if table inheritance (like PostgreSQL) would become part of some SQL standard. A high performance web application programming environment with native support for SQL data types would also be nice, to avoid converting back and forth between 'system' types and 'SQL' types (like strings with predefined collation and maximum length). In my humble opinion these two enhancements would solve much of the impedance mismatch still remaining between application and database environments. However, that will not solve the real impedance mismatch between programmers and database administrators, but I doubt anything ever will.
February 21, 2017 at 6:40 am
A lot of application developers only work with transient persistence layers, something like session state for an embedded application or the shopping cart for an eCommerce website. In that case, an object database probably makes sense. Only after the user enters their payment information and clicks the Submit button does the data get handed off to a relational database system where it's considered golden.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 21, 2017 at 6:55 am
Dennis Puliwingeefarger - Wednesday, June 17, 2009 7:23 AM...When an object database can query several classes of objects and present you with a brand new class of objects, they'll start to have something interesting...
All I can immediately think of is SmallTalk. From the 60s.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
February 21, 2017 at 8:13 am
It just doesn't add up for me, a developer, in the end. Other systems with different Non-Functional Requirements and different calling profiles and change cycles will often mean that OODBMS are not as good a fit as once thought. The productivity benefit gained in development is often lost in performance tuning. Just like with ORMs.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
February 21, 2017 at 1:30 pm
You guys crack me up, rerunning an article talking about how OO databases are always in the future from *nine years ago*.
Nine years ago I had left the industry for a new career. I came back due to client demand.
OO databases are one of 1) a pipedream, 2) a niche application. Nothing else. Never will be anything else.
I am informed why this is the case by Tony Davis: he says governance of an OO database is impossible. He is exactly right.
https://www.simple-talk.com/blogs/squaring-the-nosql-circle/
February 22, 2017 at 3:41 am
I'm not at all sure of my ground here, but my understanding is that object databases lend themselves well to scaling out whilst maintaining performance. It's not something I need to do. I need to maintain integrity, ensure good long term governance and provide analysis. This can potentially be done by a back end relational database that is kept up to date from the Object DB if you do have the massive scale out issue.
If that's the use case I understand and respect that, it's just not something I need.
February 22, 2017 at 10:11 am
I think we are creating a false tension here, and conflating multiple issues. There's a difference between needing an Object database management system (OODBMS) and needing to store, organize and retrieve documents/objects (note I use both terms, because XML is a DOCUMENT notation, whereas JSON is an OBJECT notation).
As to OODBMS in the sense of what was envisioned 10 years ago, I would fully agree that those tend to be altogether too specialized for there to be much need for a separate OS and system for that. That said - "big data" is often around storing and analyzing loosely structured or semi-structured content, which comes right down to storing a loosely or unstructured "document" of some kind; this has spawned a LOT of tooling around "schema on read discovery" efforts, heuristical analytics, etc.... So calling it "irrelevant" or "not going to happen" isn't the case anymore either.
Still - it's just yet another tool in the toolbelt: object stores, big data, etc, isn't going to replace RDBMS; alternatively, using an RDBMS to store large gobs of document data isn't a good fit either. In my view, other than having the term "database" in the title, they really don't compete with each other.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
June 25, 2017 at 6:40 pm
Gary Varga - Tuesday, February 21, 2017 6:55 AMDennis Puliwingeefarger - Wednesday, June 17, 2009 7:23 AM...When an object database can query several classes of objects and present you with a brand new class of objects, they'll start to have something interesting...All I can immediately think of is SmallTalk. From the 60s.
From the 60s? That seems to contradict the history () described by Alan Kay, the inventor of smalltalk.
The original Smalltalk (now called Smalltalk-71) was devised by Kay and others at PARC in the summer of 1971, there was nothing called Smalltalk before then. Of course that original smalltalk was just a prototype designed to prove Kay's claim that implementing a language mainly based on Simula-like message passing could be done easily (and successfully proved that) - a proof of concept rather than a useful language; it was soon followed by the first version that was used for real in the course of resarch at PARC, now known as Smalltalk-72, that was in turn followed by Smalltalk-76 and then Smalltalk-80 which was the first version released to anyone ouside of PARC (and even that was only to a limited set of people) and the first generally available version was Smalltalk-80 Version 2 which was released in 1983. so the 60s seem much too early for Smalltalk to be used for OO databases.
Tom
June 25, 2017 at 7:54 pm
It's always seemed to me that an OODBMS and an RDBMS would be two very different beasts, but both would be useful for different things. There's no reason why ACID properties can't be implemented in an OODBMS, and no reason why backup and restore can't be implemented either. Problems probably would arise if the an OODBMS used a thoroughly broken language like C++ or a hopeless mess like Java as its model for object orientation, but there are some decent OO Languages out there that wouldn't create problems. Big problems would arise if one were to use an OODBMS for something for which it was not suitable, just as they do when an RDBMS is used for something that isn't suitable.
One problem some time ago ago was that a lot of people were designing OO databases without an OODBMS, while another lot were designing OODBMSs that omitted at least one of ACID, Backup/Recovery, and Object Orientation, but there was similar silliness on the relational side. I remember people who wanted to use an OO DBMS but were horrified by the idea that calling a method of an object in the database might lead to it sending messages to other objects which in turn might send messages of their own: they didn't want objects in the database to behave as objects; and also relational database fans who were horrified by triggers, regarded cascading deletes/updates as a terrible sin, and refused to enable their foreign key constraints because they believed it would destroy performance. I stringly suspect that we still have those problems today.
Anyway, my feeling is that eventually everyone will recognise that it's case of horses for courses and both OO and R have their place. There's no possibility that Relational databases will cease to be used because they are supeceded by OO Database technology, nor any possibility that OO databases will cease to be used because evryone used Relational instead. However, it's quite possible that a better query language than SQL will arise on the Relational side, and that a decent mostly declarative query language will arise on the OO side.
Tom
Viewing 13 posts - 31 through 42 (of 42 total)
You must be logged in to reply to this topic. Login to reply