On 9/26/11, Uwe Schroeder <uwe@xxxxxxxxx> wrote: > In my experience "data formatting" goes both ways, in and out. Out is > obviously not a major issue because errors don't cause data corruption. In, > however, is a different issue. Errors in "inwards" conversion will cause > data > corruption. So unless you have an application that does very little "in" and > a > lot of "out", you still have to code a lot of data conversion which > otherwise > someone else (the postgresql developers) have already done for you. ~ Well, yes Uwe, but any code in the DBMS would slow a bit its main job which (to me) is store data and keeping its consistency as soon as possible ~ >> > Take dates for example: you'd have to code very carefully to catch all >> > the different ways dates are represented on this planet. >> >> ~ >> Yeah! And java does an exceptionally good job at that (including >> internationalization) > > Maybe it does. I never coded Java because I don't like to use technology > where > Oracle can come sue me :-) ~ Yeah! I felt like sh!t when I heard that Oracle had bought Sun, a -slightly- more open company, at least they like to keep that perception of themselves ... ~ >> http://download.oracle.com/javase/7/docs/api/java/ {util/Date.html, >> text/DateFormat.html} >> ~ >> So, you would ultimately just have to store a long value into the DBMS > > Yes, a long value - which can represent pretty much any valid and invalid > date > ever devised, so again you don't really know what's in the database when you > leave the validation to the application. ~ Not if you get that long value through java ;-) ~ >> This is something I would do with wrapping code using input and >> output bound command objects which are indexed after the same column >> index the DBMS uses > > Which still depends on your use case. Your assumption is that every piece of > code is coded in Java - which is fine if that's what your application calls > for. It's going to be a major hassle when you ever have to re-code in a > different language though. ~ Well, yes you are right ~ >> > To me, that's moving data integrity into the application. >> >> ~ >> Not exactly! Integrity is still a matter of the DBMS which can now >> handle it in an easier way in someone write a date in bangla and >> somebody else in Ukranian this is still the same date/time value >> ultimately determined by the rotation of our planet around the sun ... >> and all we need for that is a long value. Now, aren't we easying >> things for the DBMS? > > I agree to disagree on this one. The date value the database stores in this > case is a long. Any "long" can be converted into a valid date - but is it > really the date that was entered in the first place? ~ Again, not if you get that long value through java. It takes care of doing those checks for you. You could for example not enter 02/30/2011 as a date object in java and try to get a long out of it ~ > If I give a date > representation, i.e. 12/31/2010 to the database, I personally don't really > care how the database stores the date underneath. All that interests me is > that the next time I ask for that field I get 12/31/2010 back. ~ But "12/31/2010" is ultimately a representation of that long you would have inserted that was and can be represented in many different ways, depending on user preferences ~ > There is no > error that can be made other than user error if you ask the database to > store > a specific date representation. There are errors you can make in your own > conversion code which can lead to a different "long" stored than intended. ~ conversion code will not be mine and it is part of java and I would guess here python or any decent programming language ~ >> ~ >> Well, the code you will have to write either way, regardless of where >> you keep it and in order to not even have to restart the application >> server cold I would code command objects (like function pointers in C) >> to handle those cases. It is ultimately a strings of characters you >> are dealing with > > With the right design, you will have to rewrite the visual layer, not the > application logic. Errors in the visual layer are of little consequence > (except disgruntled users). So yes, if you use some kind of middleware that > does all the converting and validating for you, the difference is > negligible. > But then, why write your own when the database already provides that > functionality? ~ Because DBMS are I/O beasts and are way more likely to enter into delayed states and concurrency conflicts, so to me, the less you hassle them the better, for example I never handle http sessions with a DBMS because they are very volatile, temporary and user specific. An also, the hardware DBMSs sit on mechanically and magnetically wears off with usage ~ On 9/26/11, John R Pierce <pierce@xxxxxxxxxxxx> wrote: > its the old hammer and nail thing [1]. a pure Java programmer wants to > see everything in Java as its the tool he knows. ~ Well, not exactly. I am not religious about code. The most sophisticated code I have written in my life was in FORTRAN, but the most amount of code I have written has been ANSI C and C++ and later java, which I like because its hot spot technology enables it do run time optimizations (something you can't do with statically compiled code) which makes it faster than C on web servers ~ question: which kinds of code analysis tools do you use guys? ~ lbrtchx -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
