March 21, 2011 at 12:46 pm
The RDBMS, adhering to some strict academic definition or not, is certainly not dead or a dead end. It works extremely well for many solutions. There might be improved ways of solving some things with other products, but the RDBMS isn't dead. Also, we refer to SQL Server as being a relational database. Correct or not, you won't get anywhere by trying to change that.
In terms of developers struggling. I hear this constantly and we should evolve to make things easier to use. However developers also have some level of responsibility to learn how to use the tools useful in their jobs. Too many of them fail to make an investment in learning how data stores can work for them.
March 21, 2011 at 1:05 pm
Steve Jones - SSC Editor (3/21/2011)
The RDBMS, adhering to some strict academic definition or not, is certainly not dead or a dead end. It works extremely well for many solutions. There might be improved ways of solving some things with other products, but the RDBMS isn't dead. Also, we refer to SQL Server as being a relational database. Correct or not, you won't get anywhere by trying to change that.In terms of developers struggling. I hear this constantly and we should evolve to make things easier to use. However developers also have some level of responsibility to learn how to use the tools useful in their jobs. Too many of them fail to make an investment in learning how data stores can work for them.
You're right about all of that Steve, and thank you for bringing up this topic (again).
Amoung the real-world applications? From the wikipedia:
Real-world NoSQL deployments include Digg's 3 TB for green badges (markers that indicate stories upvoted by others in a social network),[8] Facebook's 50 TB for inbox search, and eBay's 2 PB overall data.
As for NoSQL being "Relational" or not, according to this site:
History
The term NoSQL was used in 1998 as the name for a lightweight, open source relational database that did not expose a SQL interface. Its author, Carlo Strozzi, claims that as the NoSQL movement "departs from the relational model altogether; it should therefore have been called more appropriately 'NoREL', or something to that effect."
The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge. - Stephen Hawking
March 21, 2011 at 1:36 pm
David Portas (3/21/2011)
The problem you describe is generally harder than it needs to be in SQL for at least three reasons: SQL's appalling "recursive query" syntax; SQL's lack of support for a simple transitive closure operator; insufficient physical data independence in most SQL products (this partly due to difficulties inherent in implementing the SQL model). These are not problems with the relational model, which ought to support bills of materials applications quite well. This is in fact one example of where SQL, not the relational model, has failed to meet a basic need of many applications.
"... relational model ... OUGHT TO support bills of material ..."
Well, it does not. Practical example: you need 20 number 13 bolts to assemble an automatic transmission. Then you need another 12 to mate the transmission to the engine, and another 12 to mate this assembly to the frame of the car. How many relational tables do you you need to handle this common task? (Microsoft's solution in AdventureWorks does not handle assemblies.)
Network database handles this with ease. If you are an SQLS shop and all your other systems are just fine, then you likely will have to bite the bullet and work out a design that will be ugly because it goes agains the grain of RDBMS.
March 21, 2011 at 2:15 pm
Revenant (3/21/2011)
David Portas (3/21/2011)
The problem you describe is generally harder than it needs to be in SQL for at least three reasons: SQL's appalling "recursive query" syntax; SQL's lack of support for a simple transitive closure operator; insufficient physical data independence in most SQL products (this partly due to difficulties inherent in implementing the SQL model). These are not problems with the relational model, which ought to support bills of materials applications quite well. This is in fact one example of where SQL, not the relational model, has failed to meet a basic need of many applications."... relational model ... OUGHT TO support bills of material ..."
Well, it does not. Practical example: you need 20 number 13 bolts to assemble an automatic transmission. Then you need another 12 to mate the transmission to the engine, and another 12 to mate this assembly to the frame of the car. How many relational tables do you you need to handle this common task?
Two tables to make an adjacency relation model I would guess. One to represent assemblies and one for the subassemblies / components. This is an assumption of course. It isn't practical here for me to ask the followup questions I would need to deal with all the details properly but nor is it necessary since two tables answers the general problem. Not sure why you think that is "ugly" or why you think aesthetics of the model matter at all. What exactly is the alleged "problem" you are referring to?
March 21, 2011 at 2:20 pm
Steve Jones - SSC Editor (3/21/2011)
Also, we refer to SQL Server as being a relational database. Correct or not, you won't get anywhere by trying to change that.
If you call a SQL DBMS "relational" then what do you expect me to call a DBMS that really is relational? How can we have a proper discussion about different database models if you don't use words that accurately describe them?
In terms of developers struggling. I hear this constantly and we should evolve to make things easier to use. However developers also have some level of responsibility to learn how to use the tools useful in their jobs. Too many of them fail to make an investment in learning how data stores can work for them.
You are right there. Ignorance about the relational database model and data management in general is widespread - even among database professionals at all levels.
March 21, 2011 at 2:49 pm
If you call a SQL DBMS "relational" then what do you expect me to call a DBMS that really is relational? How can we have a proper discussion about different database models if you don't use words that accurately describe them?
You are right there. Ignorance about the relational database model and data management in general is widespread - even among database professionals at all levels.
David Portas
Something that's always griped me are all these "professional" farmers, grocers, and even US Supreme Court justices, who nowadays refer to the common tomato as a vegetable, despite the fact that it clearly contains seeds.
:rolleyes:
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
March 21, 2011 at 3:07 pm
David -
Bill of material needs at least four tables. If you want to restrict types, you will need more.
My point was that in a network RDBMS it is a piece of cake.
Bill of materials is just one of those business problems that always lead to complicated, unwieldy table clusters. (This is what I meant by "ugly.")
I am not the first one who pointed this out - this is a well-documented problem.
March 21, 2011 at 3:30 pm
Revenant (3/21/2011)
Bill of material needs at least four tables.
In a SQL database maybe, not in a relational one with decent constraint support. You don't need extra tables to restrict data by type you just need the right constraints to ensure the rules are enforced. In an RDBMS it is a piece of cake.
There is no such thing as a "network RDBMS". The network model and the relational model are two different things. I guess that was just a typo on your part.
In fact the relational model is more general than the network one. A labelled graph can be represented by a ternary relation and therefore the set of relaions is much larger than the set of graphs. There is very probably nothing that can be accomplished in a network database that can't be accomplished more simply in a relational one. Added to that, a network DBMS has the drawback of being a navigational model. As I expect you know, one of Codd's goals in developing the relational model was to abolish the need to create predefined navigational structures in the database.
March 21, 2011 at 3:36 pm
David Portas (3/21/2011)
Steve Jones - SSC Editor (3/21/2011)
Also, we refer to SQL Server as being a relational database. Correct or not, you won't get anywhere by trying to change that.If you call a SQL DBMS "relational" then what do you expect me to call a DBMS that really is relational? How can we have a proper discussion about different database models if you don't use words that accurately describe them?
You'll have to help me out with your definitions here, David, if you'd be so kind? I'm afraid I'm not formally trained in database theory. What is the difference between a SQL DBMS and a Relational DBMS? SQL is the interface/communication mechanic to the Relational structure, as far as I understand it. How is a database's use of SQL make it relational or non-? It's just a language used to reference the structure.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
March 21, 2011 at 3:52 pm
David Portas (3/21/2011)
... There is no such thing as a "network RDBMS". The network model and the relational model are two different things. I guess that was just a typo on your part.
Yes, it was. Sorry for that.
... There is very probably nothing that can be accomplished in a network database that can't be accomplished more simply in a relational one.
I would have to think about an academically correct wording. In simple English, structures that in a business model can be represented as graphs that can can be mapped one-for-one onto a set of hierarchically related nodes are easier to implement in the network model.
Added to that, a network DBMS has the drawback of being a navigational model. As I expect you know, one of Codd's goals in developing the relational model was to abolish the need to create predefined navigational structures in the database.
Yes, I agree. That's why I hedged my statement by pointing out that for a great majority of business apps relational model is the best solution.
Re Codd, yes, I know his papers, from the time when they were first published in IBM Nachrichten.
March 22, 2011 at 8:12 am
I'm really enjoying RavenDB on the windows stack and MongoDB on the linux stack. I also like PostGreSQL in the RDBMS world.
Naturally, my favorite data product is SQL Server and I feel most comfortable with it.... However, as a DBA, I view my job is to handle the needs of the data/company first regardless of some sort of self imposed allegiance to a particular product/platform.
I also see a lot of flack given to NoSQL platform about eventual consistency and a bunch of other issues that can occur due to poor implementation, while not doing similar comparisons to worst case SQL Server implementations. With NoSQL I can be solving problems in minutes... With SQL Server I can't even be half way through the installer in minutes.
Chomping at the bits
March 22, 2011 at 8:19 am
DataChomp (3/22/2011)
I'm really enjoying RavenDB on the windows stack and MongoDB on the linux stack. I also like PostGreSQL in the RDBMS world.Naturally, my favorite data product is SQL Server and I feel most comfortable with it.... However, as a DBA, I view my job is to handle the needs of the data/company first regardless of some sort of self imposed allegiance to a particular product/platform.
I'd like to hear more about what database solution you're building in NoSQL and why it's a better fit than SQL Server.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
March 22, 2011 at 8:45 am
Solutions: An internal invoice system and a couple proofs of concept...The use case is basically rapid prototyping.
Why it is a better fit: The ease and flexibility of MongoDB allowed for very fast and fluid development. Could it have been done in SQL Server? Sure. Could it have been done in PostGre? Sure. But it wasn't and the world didn't come crashing down (yet 🙂 ).
EDIT: Also, if you have dev teams that are doing more rails stuff and deploying to Heroku... or wanting to use Amazon AWS (RDB/SimpleDB) ... SQL Server doesn't exist there. Sometimes, using those platforms and being flexible with your storage engine can bring more value to the products you are building than the overhead of the products you are buying.. If these other solutions outweigh the value that SQL Server brings, why would we even want to continue using SQL Server?
Chomping at the bits
March 23, 2011 at 9:35 am
Good points on the flexibility of the NoSQL choices. I have heard some good things about MongoDB, and it might work well. But prototyping and rapidly building a system from scratch doesn't necessarily make a system that will scale well or handle diverse requirements. It might, but the ease of getting started doesn't necessarily sell me.
The installed comment doesn't make sense. If you work in a SQL Server shop, you have SQL instances installed. That's a non-issue. If you install a new SQL instance for every project, I would argue that you are not proceeding with development in an efficient manner.
I can create a database and begin building objects in minutes, and see good developers easily having CRUD screens and menus done easily. There are lots of frameworks to make things easy, both with SQL Server, and with other systems.
I tend to argue that any of these technologies can work. Nothing wrong with using MongoDB, and if you have developers more skilled in PHP/Rails/non-MS language, then it might make more sense to choose another platform. However if you have C# developers, then I'm not sure switching to MongoDB makes sense.
March 23, 2011 at 10:22 am
Steve, the "install" comment was nothing more than an out of place cheap shot. Same as if I had mentioned licensing.
I would also say the MongoDB driver for C# is coming along quite nicely as well as supporting tools. But I will concede that RavenDB is a much more Windows / C# friendly solution than MongoDB. Like most technology comments, the time stamp on the comment is the critical part. What doesn't work today might work tomorrow... and of course, the inverse is true as well.
Chomping at the bits
Viewing 15 posts - 31 through 45 (of 45 total)
You must be logged in to reply to this topic. Login to reply