Re: [Pharo-project] Storing all source code in a relational database
... is a waste of time and computing resources. Relational databases are optimized for specific usage scenarios. CAD systems and source code management systems are the archetypical examples of systems that are a bad fit and will kill the performance of a relational database. Of course 30 years later you can brute force it, but that doesn't make it a good idea. Git is far superior to rdb based systems for the day-to-day work and the analytics should be done from a ram-based object model. Stephan
On 3 November 2011 00:20, Stephan Eggermont <stephan@stack.nl> wrote:
... is a waste of time and computing resources. Relational databases are optimized for specific usage scenarios. CAD systems and source code management systems are the archetypical examples of systems that are a bad fit and will kill the performance of a relational database. Of course 30 years later you can brute force it, but that doesn't make it a good idea. Git is far superior to rdb based systems for the day-to-day work and the analytics should be done from a ram-based object model.
Completely agree with you. But i think if you can store code in database, which one to use is a matter of taste (knowledge/availability etc). If we could have a nice abstraction for managing sources in image, then choosing where to store it is not a big deal.
Stephan
-- Best regards, Igor Stasenko.
Igor, I am emailing you offline but I just do not get why people are so interested in storing source code in a relational database. We have objects, there is a known mismatch between the object and relational world. So how does the relational database help out? Cincom has spent many man-years attempting to make STORE work well. A few grad students wrote ENVY in the 80's and it is a way superior in most ways to all other code repositories. Has anyone at INRIA looked at ENVY? Regards, Reg ________________________________ From: Igor Stasenko <siguctua@gmail.com> To: Pharo-project@lists.gforge.inria.fr Sent: Thursday, November 3, 2011 10:00:31 AM Subject: Re: [Pharo-project] Storing all source code in a relational database On 3 November 2011 00:20, Stephan Eggermont <stephan@stack.nl> wrote:
... is a waste of time and computing resources. Relational databases are optimized for specific usage scenarios. CAD systems and source code management systems are the archetypical examples of systems that are a bad fit and will kill the performance of a relational database. Of course 30 years later you can brute force it, but that doesn't make it a good idea. Git is far superior to rdb based systems for the day-to-day work and the analytics should be done from a ram-based object model.
Completely agree with you. But i think if you can store code in database, which one to use is a matter of taste (knowledge/availability etc). If we could have a nice abstraction for managing sources in image, then choosing where to store it is not a big deal.
Stephan
-- Best regards, Igor Stasenko.
I don't agree with that. There's certainly an impedance mismatch with Smalltalk code and relational databases, but there's also an impedance mismatch between Smalltalk code and file systems. Things like git which are custom-built to operate against a particular idea of source code and the operations on it very fast don't necessarily work well with Smalltalk-style operations like "show me the versions of this method". Cincom has spent a lot of time recently on Store, but only part of that involves the database. And much of the difficulty in the database part is not inherent to mapping the code to a database, but is because the original design of the relational schema and the way Store talked to it are very very bad, and can't easily be changed without breaking access to the database for older versions. We will change the schema to something much better at some point, but it's something that we really can't do incrementally, so we're being careful with it. ENVY has some very nice features, but I'd say that it shows some weaknesses relative to more modern systems. For example, it is very intrusive to make a version, and it is extremely sensitive to network latency. A database designed specifically for source code, and with the sort of operations that Smalltalk source code control would like to be able to do quickly would obviously be the ideal choice. Like relational databases, you'd want it to be extremely reliable, scalable, transactional, and have many different free implementations easily available on all platforms, with enough standardization that they are all reasonably compatible. A relational database isn't necessarily the best choice in all circumstances, but I don't think it's an obviously bad one either.
------------------------------------------------------------------------
Reg Krock <mailto:rkrock3@yahoo.ca> 3 November, 2011 10:42 AM
Igor,
I am emailing you offline but I just do not get why people are so interested in storing source code in a relational database.
We have objects, there is a known mismatch between the object and relational world. So how does the relational database help out?
Cincom has spent many man-years attempting to make STORE work well. A few grad students wrote ENVY in the 80's and it is a way superior in most ways to all other code repositories.
Has anyone at INRIA looked at ENVY?
Regards,
Reg
------------------------------------------------------------------------ *From:* Igor Stasenko <siguctua@gmail.com> *To:* Pharo-project@lists.gforge.inria.fr *Sent:* Thursday, November 3, 2011 10:00:31 AM *Subject:* Re: [Pharo-project] Storing all source code in a relational database
On 3 November 2011 00:20, Stephan Eggermont <stephan@stack.nl <mailto:stephan@stack.nl>> wrote:
... is a waste of time and computing resources. Relational databases are optimized for specific usage scenarios. CAD systems and source code management systems are the archetypical examples of systems that are a bad fit and will kill the performance of a relational database. Of course 30 years later you can brute force it, but that doesn't make it a good idea. Git is far superior to rdb based systems for the day-to-day work and the analytics should be done from a ram-based object model.
Completely agree with you. But i think if you can store code in database, which one to use is a matter of taste (knowledge/availability etc). If we could have a nice abstraction for managing sources in image, then choosing where to store it is not a big deal.
Stephan
-- Best regards, Igor Stasenko.
------------------------------------------------------------------------
Igor Stasenko <mailto:siguctua@gmail.com> 3 November, 2011 10:00 AM
On 3 November 2011 00:20, Stephan Eggermont<stephan@stack.nl> wrote:
... is a waste of time and computing resources. Relational databases are optimized for specific usage scenarios. CAD systems and source code management systems are the archetypical examples of systems that are a bad fit and will kill the performance of a relational database. Of course 30 years later you can brute force it, but that doesn't make it a good idea. Git is far superior to rdb based systems for the day-to-day work and the analytics should be done from a ram-based object model.
Completely agree with you. But i think if you can store code in database, which one to use is a matter of taste (knowledge/availability etc). If we could have a nice abstraction for managing sources in image, then choosing where to store it is not a big deal.
Stephan
------------------------------------------------------------------------
Stephan Eggermont <mailto:stephan@stack.nl> 2 November, 2011 7:20 PM
... is a waste of time and computing resources. Relational databases are optimized for specific usage scenarios. CAD systems and source code management systems are the archetypical examples of systems that are a bad fit and will kill the performance of a relational database. Of course 30 years later you can brute force it, but that doesn't make it a good idea. Git is far superior to rdb based systems for the day-to-day work and the analytics should be done from a ram-based object model.
Stephan
Thanks alan for this post. I think that same. :)
I don't agree with that. There's certainly an impedance mismatch with Smalltalk code and relational databases, but there's also an impedance mismatch between Smalltalk code and file systems. Things like git which are custom-built to operate against a particular idea of source code and the operations on it very fast don't necessarily work well with Smalltalk-style operations like "show me the versions of this method".
Cincom has spent a lot of time recently on Store, but only part of that involves the database. And much of the difficulty in the database part is not inherent to mapping the code to a database, but is because the original design of the relational schema and the way Store talked to it are very very bad, and can't easily be changed without breaking access to the database for older versions. We will change the schema to something much better at some point, but it's something that we really can't do incrementally, so we're being careful with it.
ENVY has some very nice features, but I'd say that it shows some weaknesses relative to more modern systems. For example, it is very intrusive to make a version, and it is extremely sensitive to network latency.
A database designed specifically for source code, and with the sort of operations that Smalltalk source code control would like to be able to do quickly would obviously be the ideal choice. Like relational databases, you'd want it to be extremely reliable, scalable, transactional, and have many different free implementations easily available on all platforms, with enough standardization that they are all reasonably compatible. A relational database isn't necessarily the best choice in all circumstances, but I don't think it's an obviously bad one either.
Reg Krock 3 November, 2011 10:42 AM
Igor,
I am emailing you offline but I just do not get why people are so interested in storing source code in a relational database.
We have objects, there is a known mismatch between the object and relational world. So how does the relational database help out?
Cincom has spent many man-years attempting to make STORE work well. A few grad students wrote ENVY in the 80's and it is a way superior in most ways to all other code repositories.
Has anyone at INRIA looked at ENVY?
Regards,
Reg
From: Igor Stasenko <siguctua@gmail.com> To: Pharo-project@lists.gforge.inria.fr Sent: Thursday, November 3, 2011 10:00:31 AM Subject: Re: [Pharo-project] Storing all source code in a relational database
On 3 November 2011 00:20, Stephan Eggermont <stephan@stack.nl> wrote:
... is a waste of time and computing resources. Relational databases are optimized for specific usage scenarios. CAD systems and source code management systems are the archetypical examples of systems that are a bad fit and will kill the performance of a relational database. Of course 30 years later you can brute force it, but that doesn't make it a good idea. Git is far superior to rdb based systems for the day-to-day work and the analytics should be done from a ram-based object model.
Completely agree with you. But i think if you can store code in database, which one to use is a matter of taste (knowledge/availability etc). If we could have a nice abstraction for managing sources in image, then choosing where to store it is not a big deal.
Stephan
-- Best regards, Igor Stasenko.
Igor Stasenko 3 November, 2011 10:00 AM
On 3 November 2011 00:20, Stephan Eggermont <stephan@stack.nl> wrote:
... is a waste of time and computing resources. Relational databases are optimized for specific usage scenarios. CAD systems and source code management systems are the archetypical examples of systems that are a bad fit and will kill the performance of a relational database. Of course 30 years later you can brute force it, but that doesn't make it a good idea. Git is far superior to rdb based systems for the day-to-day work and the analytics should be done from a ram-based object model.
Completely agree with you. But i think if you can store code in database, which one to use is a matter of taste (knowledge/availability etc). If we could have a nice abstraction for managing sources in image, then choosing where to store it is not a big deal.
Stephan
Stephan Eggermont 2 November, 2011 7:20 PM
... is a waste of time and computing resources. Relational databases are optimized for specific usage scenarios. CAD systems and source code management systems are the archetypical examples of systems that are a bad fit and will kill the performance of a relational database. Of course 30 years later you can brute force it, but that doesn't make it a good idea. Git is far superior to rdb based systems for the day-to-day work and the analytics should be done from a ram-based object model.
Stephan
participants (5)
-
Alan Knight -
Igor Stasenko -
Reg Krock -
Stephan Eggermont -
Stéphane Ducasse