Choke point

Post #29,348 by ChrisR 2/22/02 9:32:30 AM Reply	Choke point If you change a table, you are changing the data structure. Any software that uses that table is potentially impacted. By using stored procedures as filters, however, you have more localized control over how the rest of the software world handles the updated data structure - anywhere from making it totally hidden from the rest of the tasks, to requiring that all calls to the stored procedure pass an additional parameter.
Post #29,921 by tablizer 2/26/02 9:07:03 PM Reply	you looz some flexibility that way IMO >> If you change a table, you are changing the data structure. Any software that uses that table is potentially impacted.....By using stored procedures as filters, however.... << Are you suggesting starting out with nothing but stored procedures? IMO that would hamper developent. For example, if you want to join in a table that was not joined before, you have to alter the stored-procedural, and/or make a new one. I would rather see any filtering/hiding/abstracting be on an entity level in the DB, if required, so that joins can be controlled programmatically. It may also limit WHERE clause dynamism (depending on DB vendor). Flexible Boolean filtering and joining are part of what makes tables so great. You would be de-clawing them, making them no better than FORTRAN calls more or less. Regarding "changing a table", once it is populated with data, existing columns are not altered that much due to potential conversion effort. This factor tends to limit changes to existing columns, for good or bad. Thus, putting a layer over 100% of the fields to provide an abstract view of say 3% of them is not a very good expentiture of abstraction layers IMO. Spend layers wisely. ________________ oop.ismad.com
Post #29,950 by Yendor 2/27/02 10:04:16 AM Reply	Huh? Regarding "changing a table", once it is populated with data, existing columns are not altered that much due to potential conversion effort. This factor tends to limit changes to existing columns, for good or bad. Huh? Wha? I dunno anything about your work environment, but I can say that we alter tables to add and remove columns with just about every release. I'm in charge of the release process here, and we're constantly making changes to our data structure. As the system is enhanced, or features requested, we realize that it's easier to simply add a column to AnyGivenTable than to add a new table where the necessary data doesn't make sense. Granted, that's not always the case, and I'm not saying that we don't add tables. But if it makes sense to add a column to a table, then by all means, add it. Or take it away. Whatever makes sense, and provides the feature requested. Where do we have to change our code? All of our SQL calls are either in .properties files (for our Java GUI-based client) or in stored procedures on the server. Does that mean that I've got 2 places to make changes? Yep. But I'm changing the data structure, which inherently means that I will need to make changes to anything that accesses the tables in question and requires access to the new fields. Thankfully, our access points into the database are well encapsulated into .properties files. :) -YendorMike Real programmers use "vi a.out".
Post #36,932 by tablizer 4/30/02 2:08:39 PM Reply	I don't believe you (* I dunno anything about your work environment, but I can say that we alter tables to add and remove columns with just about every release. I'm in charge of the release process here, and we're constantly making changes to our data structure. ) I do see additions, but not a lot of removal of columns. ( Thankfully, our access points into the database are well encapsulated into .properties files. *) I am not quite sure what you mean. "Where to group stuff" for maintenance reasons often involves sticky tradeoffs, being that real applications deal with multiple dimensions of aspects. Grouping by aspect A will often make B-related changes harder. This is just a fact of Software Engineering. Oddly, people are blind to other dimensions beyond the one they deem King. "Encapsulation" rarely magically "just hides" everything at the right time from the right people all the time. How about a specific example. ________________ oop.ismad.com

Welcome to IWETHEY!