hug a table

Post #156,908 by tablizer 5/25/04 4:23:14 PM Reply	hug a table Er, no, that isn't the point. It's always the same format, or it Doesn't Work. You're inventing problems. It may always be the same format, but the actual values may throw off the parsing unless your reg.ex is perfect. A perfect reg.ex is sometimes a big regex, or may be beyond what reg.ex can do. I have had parses pick up the wrong stuff or ignore the wrong stuff before, so it is not "inventing" problems. Maybe you are more accurate with parsing. Lucky you. You get a gold parsing star. But I prefer to avoid parsing to process data if possible. With tables it is usually not necessary because the atoms are already isolated for us. Parsing should be a last resort. I'll take that over maintaining several databases any day. Editor. Text file. Done. I don't have to invent any tools. Everyone knows how to change them. Hell, do it in Word if you want to... that's what some of our customer interface people do. They much prefer text files over having to modify something in the database. Data-centric shops often are familiar with and accept table browsing tools. I agree that a shop needs a certain level of "investment" in tablized techniques before it is cost effective, but once you reach that point, tables are a very nice thing. I did contracts for Xbase shops where all kinds of "config" data was in tables. Every developer and operator there had no problem browing a DBF table. Oracle shops tend to use a product called "Toad". It is not the best, but works good enough. Storing the same stuff in text files seems archaic in comparison. XBase ruined me. Once you've done it with Tablina it is hard to go back to Texterina. You will sit at the lake's edge writing ballads to your lost love. Eventually Moores law will make it so that we don't have to translate tables to case lists or XML or whatever. Until then I am stuck with converting the tables to text files/scripts to get the needed speed. But tables are the wave of the future. OOP was slower than what came before it because higher abstaction needs more horse power. Similarly, the next level up (tables) needs yet more horse power. ________________ oop.ismad.com
Post #156,909 by admin 5/25/04 4:34:59 PM Reply	Re: hug a table It may always be the same format, but the actual values may throw off the parsing unless your reg.ex is perfect. Format: some.string.for.a.key=The value for it. You're inventing problems. Yes, I know you like to write where clauses to search for stuff. It Isn't Necessary. I don't even use regular expressions to grep for things. In fact, this is a stupid conversation to begin with. Here's the search process: What screen? FooScreen. OK, go to the FooScreenMessages.properties file. What language? French. OK, go to the FooScreenMessages_fr.properties file. What message key? "some.error.message". OK, open FooScreenMessages_fr.properties file, hit 'ctrl-s' for search, and start typing the key 'some.error.message'. You're inventing problems. Data-centric shops often are familiar with and accept table browsing tools. I agree that a shop needs a certain level of "investment" in tablized techniques before it is cost effective, but once you reach that point, tables are a very nice thing. We have over 1 million lines of PL/SQL source code. Huge hulking database servers. Hundreds of tables. Millions upon millions of records in them. Everyone here has a copy of Toad, and most of them can use SQLPlus without batting an eye. I hardly think we qualify as unfamiliar with table browsing tools. Storing the same stuff in text files seems archaic in comparison. It's the simplest thing that works. Putting it in tables adds nothing to the process other than overhead. But tables are the wave of the future. Keep telling yourself that. To everyone else they're just one tool among many. So to distill your arguments: use tables instead of text files because Bryce is more familiar with them. Other than that there are no tangible benefits. Since you didn't answer the other points, I will assume that you concede the overhead. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."*
Post #156,914 by tablizer 5/25/04 5:08:34 PM Reply	query and change by multiple factors Here's the search process: What screen? FooScreen. OK, go to the FooScreenMessages.properties file. What language? French. OK, go to the FooScreenMessages_fr.properties file. What message key? "some.error.message". OK, open FooScreenMessages_fr.properties file, hit 'ctrl-s' for search, and start typing the key 'some.error.message'. Yes, but if you have multiple screens to change, you end up opening and closing a bunch over and over again. Suppose you had a query like: \n select * from messages \n where appID='nerg'\n and screen='blah' and msgKey='zok' and language='french'\n Then you would only have to edit the search parameters for each one. (Some browsers can be made to prompt if you put a special marker in place of a parameter.) There is no open-open-open, close-close-close, open-open-open.... pattern that a file editor would have to keep going through. (Yeah, I know, you can write editor scripts.) And suppose we needed to change the word 'back' to 'previous' in multiple screens: \n select * from messages \n where msgText like '%back%' and language='english'\n We can then get a list, inspect it to see which ones need changing, and then change those we want. (I am assuming that we want to study each one rather than a sudden bulk change.) Your approach would take longer because you have to open and close each file/screen that needs a change. The query brings it all together in one edit-grid. In fact, the query approach will immediatly tell us how many need changing. You would have to go to grep first. ________________ oop.ismad.com
Post #156,916 by drewk 5/25/04 5:15:48 PM Reply	vim `grep -lr "search_term" *` === Implicitly condoning stupidity since 2001.
Post #156,919 by admin 5/25/04 5:19:28 PM Reply	No, no, no! Firing up Toad and running the same query in 6 different environments is MUCH better than doing that! Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,941 by tablizer 5/25/04 6:24:32 PM Reply	grep is your SQL Firing up Toad and running the same query in 6 different environments is MUCH better than doing that! Toad would already be open. So grep and goofy command-line parameters are better? And each utility invents its own. ________________ oop.ismad.com
Post #156,997 by pwhysall 5/26/04 1:02:40 AM Reply	Of course it is :) Because "grep string files" is SO much HARDER than "SELECT stuff FROM tables WHERE string=somevalue ORDER BY something;", innit? Peter [link\|http://www.debian.org\|Shill For Hire] [link\|http://www.kuro5hin.org\|There is no K5 Cabal] [link\|http://guildenstern.dyndns.org\|Blog]
Post #157,004 by tablizer 5/26/04 1:44:31 AM Reply	SQL requires much less parsing because "slots" predefined ________________ oop.ismad.com
Post #156,917 by admin 5/25/04 5:17:54 PM Reply	It doesn't work that way. Shared messages are in one file. And your ignoring the issue of promoting these changes through the environments. Until you understand that, all of this is really hand-waving. You're adding nothing other than overhead. Your approach would take longer because you have to open and close each file/screen that needs a change. It might if that were an actual change that occurred. You're inventing problems. Or let's say you're not. Let's say that someone actually comes up with that change, once. WHO CARES? You're adding overhead and complexity for one lousy change that might happen once. Sounds like a pain in the ass to me. And are you going to concede that we aren't exactly unfamiliar with databases and their uses here? Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,910 by admin 5/25/04 4:45:22 PM Reply	Question: 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? Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,918 by tablizer 5/25/04 5:18:03 PM Reply	I hate to say it, but Bill Gates is on my side WRT files 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. 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. 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. ________________ oop.ismad.com
Post #156,922 by Yendor 5/25/04 5:22:29 PM Reply	Is that supposed to be a Good Thing[TM]? -YendorMike [link\|http://www.hope-ride.org/\|http://www.hope-ride.org/]
Post #156,923 by admin 5/25/04 5:22:49 PM Reply	Oh, now THERE'S an argument. "Bill Gates said so!" So when that happens, and droves of people install Windows 2035 so they can put their I18N messages in database tables, I'll buy you a beer. Until then, answer the question: how did you do the promotion? But the real problem is that we are dealing with 2 different kinds of databases Who's the "we"? Are you talking about the current topic of discussion, or your problems keeping things in sync? Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,925 by ChrisR 5/25/04 5:24:41 PM Reply	Convergence Don't look for that convergence to be necessarily beneficial to programming for tables. Indeed, the point of the convergence, if there is a point, is to make the database look like a file system - not make the file system look like a database server.
Post #156,926 by admin 5/25/04 5:27:48 PM Reply	What "convergence", anyway? The AS/400 has been doing that for years. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,929 by ChrisR 5/25/04 5:33:45 PM Reply	But Bill Gates innovated it!!!
Post #156,937 by altmann 5/25/04 6:03:41 PM Reply	Tee hee hee I wouldn't look so fondly at WinFS if I were you. The main API is basically an OR mapping. -- Chris Altmann
Post #156,938 by admin 5/25/04 6:04:58 PM Reply	snort :-D Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,963 by tablizer 5/25/04 8:37:26 PM Reply	Not surprising. It is a hedge I wouldn't look so fondly at WinFS if I were you. The main API is basically an OR mapping. They are simply allowing it to be multi-paradigm to satifsy more customers. OODBMS are commercial failures for the most part, so they went with a hybrid approach: O-R mapping. ________________ oop.ismad.com
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]
Post #156,920 by ChrisR 5/25/04 5:19:58 PM Reply	The problem with putting config info in tables... ...is that it's quite possible that the thing you are configuring is the database itself. But then you probably knew that.
Post #156,924 by admin 5/25/04 5:24:28 PM Reply	No, no, no! You see, you have this other database that configures the first one! Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,934 by JimWeirich 5/25/04 5:54:23 PM Reply	I've seen that You see, you have this other database that configures the first one! Egads! We do that where I work now. We have a control data base tells you where all the other data bases are located. Ahhh, but how do we configure which control database to use? -- -- Jim Weirich jim@weirichhouse.org [link\|http://onestepback.org\|http://onestepback.org] --------------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
Post #156,935 by admin 5/25/04 5:56:21 PM Reply	Re: I've seen that See, you have this other database the configures the configure database...! That's a nice single point of failure, too... Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,939 by altmann 5/25/04 6:06:21 PM Reply	You're very clever, young man, very clever... ... but it's databases all the way down. -- Chris Altmann
Post #156,940 by admin 5/25/04 6:07:54 PM Reply	No, it isn't... There's the four large elephants with heads the size of continents, too... Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,995 by Ashton 5/26/04 12:39:39 AM Reply	..standing on Great A'Tuin Kinda figured it would finally emerge that all youse guys learned machine language on Discworld, in free fall over The Edge.. probably individually sentenced by Senator McTethis to that swan dive. for terminal mopery, OO and tabular thinking in a Magic field, no less This would explain.. lots.

Welcome to IWETHEY!