Re: value too long error
От | Bill Moran |
---|---|
Тема | Re: value too long error |
Дата | |
Msg-id | 40437C5F.5070607@potentialtech.com обсуждение исходный текст |
Ответ на | Re: value too long error (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: value too long error
|
Список | pgsql-general |
Greg Stark wrote: > Bill Moran <wmoran@potentialtech.com> writes: > >>In OO programming, the generally accepted rule is that a program shouldn't >>access class values directly, but the class should have methods to set >>and retrieve the data. This allows internal representations to change >>without affecting the public API of the class. It also allows data >>validation to occur, if needed. > > Note that this is largely a C++ rule. In C++ accessing class members is very > different and much less flexible than using class methods. Other OO languages > are not universally so hobbled. Really? I can only assume you're referring to languages such as perl that have ties (or equivalent capability). In that case, you're still accessing the data through a method, it's just a more abstract abstraction. Or are you referring to something else? >>I'm just wondering how far this rule of thumb could/should be extended to >>databases? I mean, you could say: "Nobody does a direct INSERT, but always >>calls a stored procedure that stores the result." I don't know how much >>this might break the mindset of the client developer. > > This is a popular old-school database approach. Personally I find it > incredibly annoying, but I can see its advantages as well. But to me stored > procedures just don't seem like nearly a powerful enough abstraction tool to > make them worth all the pain this approach entails. I threw it out there for the sake of discussion. I can see advantages and disadvantages. For example, I'm working on financial software, and _everything_ is accessed through stored procedures. This is A Good Think (in my opinion) because the software is designed to be easily integrated with other systems. The last thing we'd want is someone getting the wrong answer to a financial query because they don't understand the schema. A much more reliable way is to have them SELECT * FROM get_monthy_payment(month, account); so we know they're getting the correct answer. But I _can_ see the potential PITA this can cause. I guess it depends on the circumstance. -- Bill Moran Potential Technologies http://www.potentialtech.com
В списке pgsql-general по дате отправления: