disk I/O confusion

Post #157,268 by tablizer 5/27/04 4:07:54 PM Reply	disk I/O confusion Because there are a million other things, just as important, fighting for that RAM. But if you put it in OOP code, then it is still in RAM, no? If it is cached back and forth to disk, then you are doing what DB's do also. Or are only a small percentage of clients active at any given time? I agree that the layer between code and the DB may slow things a bit because there is a translation cost between the language and the DB, but I don't see why I/O itself would be a problem. Caching your config data in objects shouldn't take up any more RAM than caching a table it would seem. ________________ oop.ismad.com
Post #157,272 by admin 5/27/04 4:13:32 PM Reply	Different machine. And there aren't control parms at that point, because it's expressed as a connection of polymorphic or composited objects. There's no decision to be made any long because it's made at compile time. Again, the hacky solution in this case (because it's still in PL/SQL) was to create a binary search tree in IF/THEN code that is called instead of selecting from the table. Added maintenance and coding overhead, but there you go. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #157,299 by tablizer 5/27/04 5:30:45 PM Reply	parameter view and flex questions And there aren't control parms at that point, because it's expressed as a connection of polymorphic or composited objects. There's no decision to be made any long because it's made at compile time. What if somebody wanted to study all those "parameters" such as doing queries and reports on them? Usually in a mega-size operation like you claim to be, somebody starts wanting such info. It may even be useful for debugging. Grep again? Or, wrote new sections in another language that also needed access to the same parameters? Or, change them during run-time instead of having to recompile? ________________ oop.ismad.com
Post #157,316 by admin 5/27/04 6:47:52 PM Reply	Re: parameter view and flex questions What if somebody wanted to study all those "parameters" such as doing queries and reports on them? Grep would be sufficient. Nothing more complex is needed. Typically the division of code is such that no search is needed, as it's fairly obvious where to go to find the information. Any other configuration isn't worth the trip to the database. Or, wrote new sections in another language that also needed access to the same parameters? We'll deal with that when it happens. Clue: it isn't likely. This is a complete subsystem; there's no reason to introduce other languages. We have 4 languages here: PL/SQL, C++, Java, and Perl. PL/SQL is for database internal operations and UI (previously), C++ for communications, Java for UI (now, not previously), Perl for build system. Language independence simply isn't important, nor is it in general. Decision points aren't shared; data is. Or, change them during run-time instead of having to recompile? Doesn't happen. These sorts of changes happen at most nightly. During production, not at all. During development, doing a recompile is no more burdensome than reloading the parms, given the procedure we have to go through to convert them to the binary search stored procedure. Adding the ability to change at runtime is only useful during development, and it's such a minor gain that it's not worth the other hassles. This isn't binary, Bryce. "Ah ha! I found one reason it's better!" Tabled parms have a few advantages, but in toto are outweighed heavily by the disadvantages. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #157,470 by tablizer 5/28/04 3:52:55 PM Reply	perfect un-storm This isn't binary, Bryce. "Ah ha! I found one reason it's better!" Tabled parms have a few advantages, but in toto are outweighed heavily by the disadvantages. It just seems like your shop is a "perfect storm" situation where the problems of TOP are magnified and none of its benefits are desired by management and customers. ________________ oop.ismad.com
Post #157,477 by admin 5/28/04 4:06:00 PM 5/28/04 4:09:53 PM Reply	Re: perfect un-storm In reverse order: The customers desire that the application works, and that it is stable, and that it is fast. "TOP" reduces performance and increases maintenance overhead (which causes bugs), and is hence undesireable. Management desires that its programmers don't spend time writing needless utilities to do stuff that isn't necessary in the first place, like versioned database tables. Management desires that we do what works, which is contrary to spinning our wheels on self-inflicted maintenance headaches. The problems of TOP are magnified because it is a large shop. The same problems are always there, but when writ large they become glaringly apparent. At some point of smallness, however, they become negligible enough that you don't notice them. Given that you've already stated that TOP's benefits are those of scale (managing 1000s of rows as compared to 10s) and that OO and other techniques are fine or even better for small applications, and that now you've admitted that TOP doesn't scale to large applications (and in fact in order to give it any semblance of maintenance scalability, you have to adopt OO-like techniques like building your own jump tables), I'm not quite certain where your middle ground lies... Well, actually I am, but I'm not quite certain that you have realized it yet. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..." Edited by admin May 28, 2004, 04:09:53 PM EDT Expand All History
Post #157,494 by tablizer 5/28/04 6:44:05 PM Reply	the rule or the exception Management desires that its programmers don't spend time writing needless utilities to do stuff that isn't necessary in the first place, like versioned database tables. The fact that there are not very many existing products for such suggests that it is not a common need. (I suppose you will argue this is because most will move to files instead if they need such, but many may not want to make that leap for an existing system.) you have to adopt OO-like techniques like building your own jump tables I don't know why you keep saying this. The table already exists. I am just sticking function names in it. If not, it is no more effort than building a bunch of classes. You make it sound like I am doing something extra. The amount of finger work is not more. Given that you've already stated that TOP's benefits are those of scale (managing 1000s of rows as compared to 10s) and that OO and other techniques are fine or even better for small applications, and that now you've admitted that TOP doesn't scale to large applications.....I'm not quite certain where your middle ground lies If by chance your shop needed more feature-usage reporting/querying or needed faster configuration changes (rather than recompiling for each change), then you would be more open to such. Whether your current condition is the rule or the exception is probably another 500-message flame-war. ________________ oop.ismad.com
Post #157,509 by admin 5/28/04 9:55:07 PM Reply	Re: the rule or the exception The fact that there are not very many existing products for such suggests that it is not a common need. Because it's a poor idea. If you think otherwise, build the tool and have everyone beat a path to your door. I don't know why you keep saying this. The table already exists. And why does the table exist? So you can put function names in it. Then jump to them. That is, a "jump table". You make it sound like I am doing something extra. Managing databases is more labor intensive than managing code, so you are, in fact, doing something extra. Let's say you need a new one, which requires adding another column. Ever do that in a large shop? Or even a medium-sized shop? Hint: my company is on the smaller end of "medium sized enterprise". If by chance your shop needed more feature-usage reporting/querying or needed faster configuration changes (rather than recompiling for each change), then you would be more open to such. Feature-usage reporting/querying is a low-priority item no matter where you are. Configuration changes are by their very nature fairly rare. Set it up once and it's done. You are simply not filling a need. And what little need there may be for such a thing is over-balanced by the deficiencies of the technique. And given that I can do the same thing in OO by using a table as well, there really is no compelling reason to use the technique at all. Whether your current condition is the rule or the exception Come back to talk about it more when you've actually worked in something besides a small shop. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #157,609 by tablizer 5/29/04 5:50:13 PM Reply	shop size phalic symbols Because it's a poor idea. Why is it a poor idea? People need to keep track of more things that just code. I think it is not common because it is relatively easy to add your own tracking. Managing databases is more labor intensive than managing code, so you are, in fact, doing something extra. Let's say you need a new one, which requires adding another column. Ever do that in a large shop? Or even a medium-sized shop? I have worked in medium-large companies that divide projects into smaller project rather than one-big-EXE. Perhaps you guys are not partitioning properly. Adding a new column in Microsoft SQL-Server was a snap. I can't really speak for Oracle. Oracle is not known for its RAD abilities. People buy it for speed and reliability, not for nimbleness. Feature-usage reporting/querying is a low-priority item no matter where you are. Tell that to the sales/marketing department. They always want to know what customers want so they can hype it and/or make yet more features related to existing favorite features. ________________ oop.ismad.com
Post #157,620 by admin 5/29/04 6:54:58 PM Reply	Re: shop size phalic symbols Why is it a poor idea? Did we, or did we not, just go through how many hundreds of posts on this very subject, at the end of which you said, "You Win!"? I have worked in medium-large companies that divide projects into smaller project rather than one-big-EXE. Perhaps you guys are not partitioning properly. What does this have to do with the price of tea in China? I said, "Managing databases is more labor intensive than managing code, so you are, in fact, doing something extra." This is why people hire full-time DBAs (we have two full-timers, and one part-timer), because it takes more effort to manage a database. What in Hades does this have to do with partitioning? An extra database is an extra database. Adding a new column in Microsoft SQL-Server was a snap. And how did you put that change under revision control? How did you promote that change to production? Or even QA? Of course adding a column is a snap if you aren't managing it properly. Tell that to the sales/marketing department. Oddly enough, our sales people know what the applications do without searching source code. They also know what the client's are requesting and using. It's called, "specifications" and "documentation". You ought to try it sometime. Concession noted for posterity (judging by your failure to respond): you admit that you are in fact creating a jump table as described. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #157,660 by tablizer 5/30/04 1:50:20 AM Reply	DBAs != "extra" Did we, or did we not, just go through how many hundreds of posts on this very subject, at the end of which you said, "You Win!"? I meant the concept of verson control for DB's. "Managing databases is more labor intensive than managing code, so you are, in fact, doing something extra." This is why people hire full-time DBAs... No. Hiring DBA's is a "divide and conquer" strategy. DBA's focus on data stuff and app developers focus on providing algorithms for specific tasks that have to be accomplished based on the data. The idea of a hybrid DBA/developer, such as what XBase used to make common, was mostly rejected because developers tended to make messes such as poorly normalized schemas and no longer-term design strategies. Such apps may have worked fine in isolation, but biz often wants to share info with multiple apps. Concession noted for posterity (judging by your failure to respond): you admit that you are in fact creating a jump table as described. However you label it, it is not more effort than doing the same in a class. ________________ oop.ismad.com
Post #157,681 by admin 5/30/04 9:18:24 AM Reply	Re: DBAs != "extra" I meant the concept of verson control for DB's. Revision control for DBs is fine. We use it ourselves. Via files. And then when it came time for you to describe why doing it in the database was better, you said "You Win!" No. Hiring DBA's is a "divide and conquer" strategy. Because managing a database takes more knowledge and effort than managing a source code control repository, as you have apparently conceded by failing to respond to my questions about adding a new column. Additionally, adding an extra database involves even more work, unlike using a single source code repository. However you label it, it is not more effort than doing the same in a class. Nope, no back-tracking here, Bryce. I've already established and you've already conceded that maintaining control tables [link\|/forums/render/content/show?contentid=157245\|is more work]. Concession noted for posterity: reporting on code is useless for the sales/marketing people given specs and documentation. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #157,737 by tablizer 5/30/04 4:19:53 PM Reply	There is more to life than version control And then when it came time for you to describe why doing it in the database was better, you said "You Win!" I meant if there would be a market for DB-centric version control. Because managing a database takes more knowledge and effort than managing a source code control repository, as you have apparently conceded by failing to respond to my questions about adding a new column. I meant in general. I conceed that existing DB-centric version control management tools are weak. But your claim seemed more general-scoped, not just about version control. Some shops don't care that much about version control (for good or bad, its their decision). ________________ oop.ismad.com
Post #157,743 by deSitter 5/30/04 5:13:25 PM Reply	Bryce, come to Philly on 7/4 I will sell tickets to see you and SA go at it. It's wonderful, minds that still function in IT. -drl
Post #157,748 by admin 5/30/04 6:03:37 PM Reply	Might be fun. I'd rather just talk about shit, though, than go at it in person. We can talk shop all day here. Philly is for beer and chat, and I'd be more than happy to sit down with Bryce and a beer and shoot the shit. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #157,801 by tablizer 5/31/04 12:02:37 AM Reply	warning: alchohol makes me irratable Most say it relaxes them, but it makes me want to bust OO fans in the choppers instead. Gotta find a different legal relaxor. ________________ oop.ismad.com
Post #157,747 by admin 5/30/04 6:03:23 PM Reply	Re: There is more to life than version control I meant if there would be a market for DB-centric version control. Something that snaps into CVS/PVCS/SourceSafe/whatever and makes it dead stupid simple to do, perhaps. But it would have to work with current source code repositories, which means file-based. People aren't going to want a separate tool with a separate repository, nor will they want something that requires maintaining an extra database instance. Some shops don't care that much about version control Such shops aren't likely to care about much of anything worth caring about either. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #157,797 by tablizer 5/30/04 11:59:19 PM Reply	Dilbert reigns Such shops aren't likely to care about much of anything worth caring about either. Most shops are highly Dilbertian. That's life in Corporate American. ________________ oop.ismad.com

Welcome to IWETHEY!