I'm glad you admit it

Post #156,962 by ben_tilly 5/25/04 8:35:42 PM Reply	I'm glad you admit it Have you ever worked in a place that has multiple database environments (dev, test, qa, etc.) that promoted configuration information between the environments? If so, how was the promotion performed? Yes, and sometimes things did get out of sync, I will admit. I'm glad you admit it. Because what you just said is that you don't have a solution for the problem that Scott is talking about, and you had bugs because of it. Not possible bugs. Not woulda, shoulda, couldas. But actual maintainance problems. That you didn't figure out a solution to. Now all that you have to do is see how, when you are using version control anyways, that problem is eliminated. But the real problem is that we are dealing with 2 different kinds of databases: a file system (hierarchical) database, and a relational database. Microsoft, for one, is seriously thinking about merging them so that they will not be different things. Thus, migrating files (if we still call them that) and migrating config data will be the same thing. No, that isn't the real problem. The real problem is that we have data of different types. (Note that code itself is just data.) Different types of data move in separate ways, and so should be maintained separately. Application data generally does not move, people on production generate production data. You don't want to "promote" test data to production. Configuration data and code data tend to move in the same way at the same time. Therefore putting them together in revision control makes sense. The standard development toolkit includes things like revision control systems, editors, searching utilities, make, etc. As long as the state of the art for these is not as well-developed on the database as on regular filesystems, that is an argument for using filesystems for code and configuration data. Convergence is coming! You flat-file-tree-and-code lovers will be the New Luddites and I will be playing a nano-violin to soothe your sorry soul. If the standard development toolkit is all available for data backed by relational databases, few developers will notice or care when they switch. You still like having configuration information under revision control for the same reasons that applied before convergence. To the extent that Microsoft breaks that toolkit, their environment, convergence or no convergence, remains inferior for development purposes. Cheers, Ben To deny the indirect purchaser, who in this case is the ultimate purchaser, the right to seek relief from unlawful conduct, would essentially remove the word consumer from the Consumer Protection Act - [link\|http://www.techworld.com/opsys/news/index.cfm?NewsID=1246&Page=1&pagePos=20\|Nebraska Supreme Court]
Post #157,253 by tablizer 5/27/04 3:10:59 PM Reply	Today and Tommarow Not possible bugs. Not woulda, shoulda, couldas. But actual maintainance problems. That you didn't figure out a solution to. I did not have the authority to do anything about it even if I wanted to fix it. I have already agreed with Scott that with the existing state-of-the-art and existing tools, files may indeed be the way to go for his needs. To the extent that Microsoft breaks that toolkit, their environment, convergence or no convergence, remains inferior for development purposes. Relational is a more powerful abstraction than tree-base file systems. Often tools that rely on older abstractions will break when a switch is made to newer improved abstractions. It is roughly analogus to moving from 8.3 DOS file names to long names. Or, trying to print graphics on a text-only printer. Note that one can still emulate file trees in relational the same way one can still use 8.3 file names in newer tools, but when people start using the full power of relational, those old-style tools probably won't work well. ________________ oop.ismad.com
Post #157,263 by folkert 5/27/04 3:35:04 PM Reply	Today IS tomorrow I have already agreed with Scott that with the existing state-of-the-art and existing tools, files may indeed be the way to go for his needs. Well, I'd say this will ALWAYS be true. Tools that are currently existing, will always be used. Relational is a more powerful abstraction than tree-base file systems. Often tools that rely on older abstractions will break when a switch is made to newer improved abstractions. It is roughly analogus to moving from 8.3 DOS file names to long names. Or, trying to print graphics on a text-only printer. Note that one can still emulate file trees in relational the same way one can still use 8.3 file names in newer tools, but when people start using the full power of relational, those old-style tools probably won't work well. Yes, using a relational abstraction is all well and good, may actually be a good way to head towards. But, there will nearly always be a hierarchy that tree-based file systems will be good for. Right now the AS400 currently has a DB for a file-system. Pretty much as you'd want, just not as extensible as you'd prolly like though. When those tools that rely on the OLD-WAY of doing things are properly maintained, they will use the "legacy" abstractions if they are there, and the new ones when they are there. It really depends on the piece between the keyboard and the chair, in terms of how things are used. CVS(with RCS) in and of itself is a database, a database of code and changes to that code. In effect your tool is already there, it just has to back-ended differently. Relational can pertain to OOP and TOP, there really is no distinction between the programming methods when looking at it from a relational standpoint. The things you bring up... OOP is TOP, when dealing with a database. Why would you do anything else? When dealing with a Database, you are having to orient your Data towards a normalization, then code the application(s) or queries to your tables. Rough analogies are just that, rough. 8.3 -> LFN doesn't compare. Printing doesn't really compare either. It's all about perception. Many of those old tools that are here now, have been migrated through many many years of methodologies... and will continue to migrate with the current methodologies, as well as sometimes allow extensions to current methodologies. Either way, many of the "old favorties" will have all the old features (undocumented or not) and plenty of new ones. -- [link\|mailto:greg@gregfolkert.net\|greg], [link\|http://www.iwethey.org/ed_curry\|REMEMBER ED CURRY!] @ *i_wethey* Give a man a match, he'll be warm for a minute. Set him on fire, he'll be warm for the rest of his life!
Post #157,285 by ben_tilly 5/27/04 4:59:19 PM Reply	"More powerful abstraction" has no absolute meaning Abstractions need to be fitted to the use to which they are put. A great abstraction that doesn't fit how you need to work sucks for that purpose. A limited abstraction that happens to be a great fit can be very good. Now the relational abstraction is very powerful. And is very good for a lot of things. But it is not directly a very appropriate abstraction for many development tasks. You should not have to type in a line of SQL to edit a line of code. Therefore I'll reiterate, it does not matter how powerful the relational abstraction is, if a high-quality toolkit (with its own abstractions) that is appropriate for development has not been built on top of the relational one, then it is better to manage your code outside of a relational database. Cheers, Ben To deny the indirect purchaser, who in this case is the ultimate purchaser, the right to seek relief from unlawful conduct, would essentially remove the word consumer from the Consumer Protection Act - [link\|http://www.techworld.com/opsys/news/index.cfm?NewsID=1246&Page=1&pagePos=20\|Nebraska Supreme Court]

Welcome to IWETHEY!