misunderstanding

Post #157,054 by tablizer 5/26/04 12:49:28 PM Reply	misunderstanding Ah... finally... text files. Thank you. So all of your garbage about the database being better for managing configuration information has been crap, because in the end you have to load it from text files in the first place. I did not say anything about putting data in text files there. The script I talked about would create and copy relavant database info from say the development DB environment to the testing DB environment, etc. Promote means moving the code from one environment (dev) to the next (test, QA, prod). I usually hear that called "migration". And get it through your head: this is an Oracle shop, not a Java shop. I bet you are trying to change that. ________________ oop.ismad.com
Post #157,064 by admin 5/26/04 2:38:55 PM Reply	Re: misunderstanding I did not say anything about putting data in text files there. The script I talked about would create and copy relavant database info from say the development DB environment to the testing DB environment, etc. And when your development database is rebuilt every night? How do you prime it in the first place? How do you track revisions? How do you migrate one change and not another? I bet you are trying to change that. No, there are an awful lot of things that belong in the database. Code isn't one of them. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #157,066 by ChrisR 5/26/04 2:43:12 PM Reply	Well... I pack up my development database and... ...take it home with me every night. :-)
Post #157,071 by folkert 5/26/04 3:30:05 PM Reply	How do you prime it in the first place? Usually, using a siphon, FIFO or primer pump. DUH. -- [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,078 by Another Scott 5/26/04 3:41:04 PM Reply	I prefer Kilz myself.
Post #157,082 by folkert 5/26/04 3:51:37 PM Reply	That works well... For the crayon markup he does... nice suggestion. -- [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,083 by tablizer 5/26/04 3:54:38 PM Reply	The file system is a database And when your development database is rebuilt every night? How do you prime it in the first place? How do you track revisions? How do you migrate one change and not another? They are many different approaches. I would need a specific use-case to suggest something. I am sure many large firms have faced the issues of schema and config data management. Most places I am familiar with had too many manual processes in place and seemed strangely uninterested in automating such stuff, perhaps out of job loss fear. But there may be tools out there to help with such. I agree that management-by-file tools are further along and more available. Schemas and stuff are tables themselves, so it is possible to perform operations on those tables just like any other; however, companies like Oracle seem to make it more difficult than it has to be it seems to me. there are an awful lot of things that belong in the database. Code isn't one of them. Like I said, the file system is a database, just not a relational one. They are currently treated differently by different tools, but I expect/hope that will eventually change. I see no logical reason to distinguish between a file system and a database system. The current conventions are archaic. ________________ oop.ismad.com
Post #157,090 by admin 5/26/04 4:48:29 PM Reply	Re: The file system is a database Here's the use case: You have a development database. It's rebuilt every night. There's a parm table that is used to make decisions during execution. How do you: 1) Get the data into the dev database in the first place after each rebuild. 2) How do you track revisions between the different changes? Someone changes one parm, someone else changes another. Now you need to migrate the one change but not the other. 3) Create a new dev instance on a developer's PC so they can work locally. Basically you're telling me that there are no tools that you're aware of to do this, and that it's pretty much a manual process unless you want to spend a lot of time automating it. Most places I am familiar with had too many manual processes in place and seemed strangely uninterested in automating such stuff, perhaps out of job loss fear. Oddly enough, we've completely automated this process here... using the proper tools for the job: files. I agree that management-by-file tools are further along and more available. So parm tables: 1) Execute more slowly at runtime. 2) Require more maintenance. 3) Require manual tracking of revisions. 4) Require manual migration procedures. 5) If automated, require completely different migration procedures than everything else in the build. Or I can use OO methods and get both automatic migration tools and maintenance benefits as I have described elsewhere. Concession noted. The current conventions are archaic. The current conventions work. The new conventions you are describing have no tangible benefit other than "Bryce likes them more", and plenty of deficiencies. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #157,113 by tablizer 5/26/04 7:27:42 PM Reply	over-the-phone brain surgery I would have to study the nature of the business to make any recommendations. I don't work there. Maybe there is a grand table way to clean it all up, but I cannot offer such very well only knowing bits and peices. It is like doing brain surgery over the phone. If you want more info on database versioning tools, go look it up yourself. Or, stay with your comfy archaic files. Basically you're telling me that there are no tools that you're aware of to do this, and that it's pretty much a manual process unless you want to spend a lot of time automating it. I don't know that it would be a lot of time automating it. Tables are usually easy to work with. Maybe you just need more nimble languages or something. Oddly enough, we've completely automated this process here... using the proper tools for the job: files. By (your) definition. The current conventions work. So does assembler and goto's. The new conventions you are describing have no tangible benefit other than "Bryce likes them more", and plenty of deficiencies. They are only "deficiencies" because you like to work with files instead of tables. Don't tell me about "liking them more". Relational tables are a more powerful concept than files. Even with file-bigotted tools they still usually lead. The limits of files and directories cause headaches in many of projects I deal with. Maybe files work faster at your place because they are like assembler: Primative and annoying, but fast. ________________ oop.ismad.com
Post #157,115 by admin 5/26/04 7:39:07 PM Reply	Re: over-the-phone brain surgery I would have to study the nature of the business to make any recommendations. Hand waving. Make something up. It's very simple. How would you do it? You said that you've been at places where it was a manual copy. That's it? Nothing better? If not, then your way loses. I don't know that it would be a lot of time automating it. So you've never worked some place that has requirements like this. You just slam the control table data right into production. If this is true, then no wonder you think this is an acceptable way to do things. So does assembler and goto's. Nope. Assembler and GOTOs take considerably more development effort. Try again. They are only "deficiencies" because you like to work with files instead of tables. So the performance problems are there because I like to work with files? And manual database migration strategies suck because I like to work with files? Are you serious? Relational tables are a more powerful concept than files. Even with file-bigotted tools they still usually lead. "Usually" as in "a project Bryce worked on once". They're more powerful for DATA, not CODE. The limits of files and directories cause headaches in many of projects I deal with. Oh, really? Care to back that up? What headaches? Maybe files work faster at your place because they are like assembler: Primative and annoying, but fast. Hardly primitive. I can sit down with a blank system, type one command (bexvm build -d SID) and create an entire, running copy of our system, loaded config data, compiled code, everything. Unattended. This is primitive? You must be using a different dictionary than I do. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #157,161 by tablizer 5/27/04 1:29:08 AM Reply	a single command does not like databases? Make something up. It's very simple. How would you do it? For migration? Just copy it over. As far as revision tracking, let's assume your config table looks something like this: Table: clientConfig ------------------ clientRef paramID paramValue You can set a trigger(s) such that every time a record is added, changed, or deleted, the change is copied to a log that looks something like: Table: clientConfig ------------------ clientRef paramID paramValue changeType // add, change, or delete changedWhen who // login ID of changer (if avail.) With this info, one can recreate any time period and study all changes. (I here some RDBMS have such "delta-log" features already built in.) So you've never worked some place that has requirements like this. There are a lot of domains and situations that I have never encountered. I just know that tables are more useful and flexible than files most of the time. If you found an exception, so be it. Nothing is 100% always the best solution. Nope. Assembler and GOTOs take considerably more development effort. So does dealing with Flinstonian file systems. They're more powerful for DATA, not CODE. And config info is data. Oh, really? Care to back that up? What headaches? I can't easily query the file system to find or view files how I want. Yeah, I know, if I learned grep and other file utils well I could probably eventually do the same, but why learn two query languages? Plus file systems don't have indexes on attributes outside of the tree. Thus, it has to do a sequential search for many operations. I have heard multiple times from developers how they wish they could query the file system using SQL and/or add extra attributes to files or directories to mark stuff for various purposes. I have seen companies jump thru hoops because they couldn't add custom file attributes. They have to keep a seperate list(s) of file info. Hardly primitive. I can sit down with a blank system, type one command (bexvm build -d SID) and create an entire, running copy of our system, loaded config data, compiled code, everything. Unattended. This is primitive? How does tabling info preclude the use of a single command to initiate everything? ________________ oop.ismad.com
Post #157,180 by admin 5/27/04 9:16:09 AM Reply	Re: a single command does not like databases? There are a lot of domains and situations that I have never encountered. I just know that tables are more useful and flexible than files most of the time. Do you see how these two statements are incompatible? You don't know that tables are more useful for situations you've never encountered. So does dealing with Flinstonian file systems. Which you haven't shown. So far you've shown that using tables for config information requires more overhead. And config info is data. Thou sayest. I can't easily query the file system to find or view files how I want. Not this again. Concession granted. You have a mental block against grep. Sad state to be in, but I'll give you that. Now the amazing thing is, every company I've worked with hasn't had these "headaches". Given the vast range of tools available today for working with source code, it just isn't a concern. How does tabling info preclude the use of a single command to initiate everything? How is using a single command "primitive"? Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #157,219 by tablizer 5/27/04 12:46:38 PM Reply	Re: single command Do you see how these two statements are incompatible? You don't know that tables are more useful for situations you've never encountered. When you encounter a new application to build or enhance, do you automatically use OO? If not, what do you automatically use? You have to have some default, otherwise you do nothing. Not this again. Concession granted. You have a mental block against grep. Sad state to be in, but I'll give you that. Now the amazing thing is, every company I've worked with hasn't had these "headaches". Given the vast range of tools available today for working with source code, it just isn't a concern. Sure, if you get used to ANY primative tool, you will eventually learn to love the bomb. How is using a single command "primitive"? I did NOT say that. Commands are orthogonal to OO and files, BTW. ________________ oop.ismad.com
Post #157,240 by folkert 5/27/04 1:55:32 PM Reply	Naw... you are thinking... Commands are orthogonal to OO and files, BTW Naw... HEXAGONAL, that way they are cursed[1] before you use them. Therefore no chance they can be cursed additionally. [1] curses using. -- [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,247 by admin 5/27/04 2:46:30 PM Reply	Re: single command When you encounter a new application to build or enhance, do you automatically use OO? If not, what do you automatically use? You have to have some default, otherwise you do nothing. No, I do not have a default. I look at the requirements and choose amongst several tools, which for me includes RDBMSes, OO programming, and so on. Bryce, I work at a place that is your wet dream. 1 million lines of procedural RDBMS code, using control tables, parms, and IF/THEN blocks. I have direct experience with this. You have none. Yet you feel qualified to wave your hands and scream "tables are better!" when I have direct empirical evidence that they are not. There are 30 PL/SQL developers here who prefer to manage their configuration information in FILES. Every single one of them has TOAD on their computers and use it daily. They don't want the overhead, and they understand the issues. You do not, and you've got your fingers in your ears while I'm trying to demonstrate this to you. Perhaps on a small scale you may find them more convenient. Fine. I do not, these people do not, and your techniques simply do not scale. And quite frankly, if I have to draw my programmers from a pool that is mostly people who work on smaller apps, I'm going to look for people who know how to deal with files because that's what works best at this scale. And all the hand-waving in the world won't change that. Sure, if you get used to ANY primative tool, you will eventually learn to love the bomb. Perhaps if I were working with a "primative" tools, I would. But I'm not. Given that there exist no tools for doing revisions of database tables, and there are for files, which is the primitive tool? I did NOT say that. Commands are orthogonal to OO and files, BTW. What you said was "How does tabling info preclude the use of a single command to initiate everything?" Which is not what you were asked. You were asked: Hardly primitive. I can sit down with a blank system, type one command (bexvm build -d SID) and create an entire, running copy of our system, loaded config data, compiled code, everything. Unattended. This is primitive? To which your response made no sense at all, so I reiterated. Answer the question: is that primitive, yes or no? No weaseling, no hand-waving. Answers other than yes or no will be ignored and the question posed again. So does dealing with Flinstonian file systems. Which you haven't shown. So far you've shown that using tables for config information requires more overhead. No response, so concession noted. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #157,182 by admin 5/27/04 9:16:20 AM Reply	Database migrations (new thread) Created as new thread #157181 titled [link\|/forums/render/content/show?contentid=157181\|Database migrations] Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #157,280 by mmoffitt 5/27/04 4:52:26 PM Reply	Nit: some code does belong in a database. (sp's) bcnu, Mikem If you can read this, you are not the President.

Welcome to IWETHEY!