Re: (another ;-)) PostgreSQL-derived project ... - Mailing list pgsql-general

On 9/25/11, David Johnston <polobo@yahoo.com> wrote:
> On Sep 25, 2011, at 2:11, Albretch Mueller <lbrtchx@gmail.com> wrote:
>> Can you or do you know of anyone who has made those kinds of
>> imaginations falsifiable?
>
> No; not worth my effort.
~
 ;-)
~
>>> That approach strips down on application complexity. My apps don't have
>>> to do any post-processing of the data - I query the records I need and
>>> the app merely displays them.
>> ~
>> Again have you actually tested those assumptions?
>
> Is this the best response you can come up with? The crux of the
> counter-argument is that by having PostgreSQL handle 'advanced' features
> application code avoids the need to do so.  The principle of code-reuse and
> the fact the features are executed by the same program holding the data make
> this a de-facto truth (and yes, one that we are probably taking for
> granted).
~
 First, I wonder what kind of technical person would say there are
"de-facto truth(s)". I thought only politicians would talk like that.
Now, in a sense you are right, I am talking from the background of my
own experiences (and so are you). When I have developed relatively
complicated and heavily accessed websites I only use DBMS when I need
to actually persist any data. For example there are options in Tomcat
(the java-based web serverrr) to offload session handling to a DBMS
(which is great when you need to stat(istically trace and infer users'
navigation) and establish transactions offloading a timed-out session
to an actual database hitting thhard drivevee (some user got
distracted ...) ...) and that sounds great, but anything dealing with
I/O would invariably slow your apps, so what I do is use in-mem (lite)
DBMS such as Hypersonic SQL (hsqldb.org) to keep sessions off the I/O
subsystem and the speed increase is --very-- noticeable
~
 Since any piece of code engaging the I/O such as database access code
should be as fast and simple as possible; yes, I would design, say,
java code wrappers doing anything that is not strictly INSERT and
SELECT raw data ... let me deal with the "semantics" and "business
intelligence" of the data myself
~
> But, if you really feel a bare-bones implementation of PostgreSQL
> is worthwhile you are the one that needs to test (and state explicitly) your
> own underlying assumptions to see whether they hold and thus make such an
> endeavor worthwhile.
~
 you are right and I am up to it
~
On 9/25/11, Alban Hertroys <haramrae@gmail.com> wrote:
>>> ... and can now use those features within my SQL statements/queries.
>> ~
>> For what exactly? Isn't a comparison on 4 numeric bytes (1 (or 1/2)
>> word in modern hardware) more efficient than comparing sequences of
>> string characters?
>
> Data types aren't stored in the database as character strings (unless you
> define your columns as text, of course).
~
 I was talking about text and any formatting option in NUMERIC or DATE data
~
On 9/25/11, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Albretch Mueller <lbrtchx@gmail.com> writes:
>>  Well, at least I thought you would tell me where the postgresql-base
>> is to be found. The last version I found is:
>>
>> http://freebsd.csie.nctu.edu.tw/pub/distfiles/postgresql/postgresql-base-8.3beta2.tar.bz2
>>  and I wondered what that is and why there are no postgresql-base
>> after "8.3beta2"
>
> We stopped bothering because the split tarballs weren't really good for
> anything separately ...
~
 Thank you for answering my question
~
> Now, having said that, there has been some interest in pushing
> lesser-used chunks like the geometric datatypes out into extensions ...
~
 Yes, that is it, extensions! It would be great if PG could be built
in a more modular way, with just the features you need. Clusters of
dependencies will have to be checked ... I think that would enrich PG
development
~
On 9/25/11, Uwe Schroeder <uwe@oss4u.com> wrote:
>
>> > ... you're looking for a non-sql compliant SQL database where a lot of
>> > the data integrity is actually coded in the application :-)
>>
>> ~
>>  First past of your statement I acknowledged, but how is it exactly
>> that "lot of the data integrity is actually coded in the application"
>> ~
>
> 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)
~
 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
~
 I am amazed to read that you/the PC community were still running
regression tests in ASCII
 http://www.postgresql.org/docs/9.1/static/release-9-1.html
(E.1.3.12. Source Code)
 * Run regression tests
(postgresql.org/docs/9.1/static/install-procedure.html#BUILD) in the
default encoding (Peter Eisentraut)
 Regression tests were previously always run with SQL_ASCII encoding.
~
> Same goes for numbers: if everything is stored in a byte sequence, how does
> the database know you try to compare the number 1 with the character "1"?
~
 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
~
> 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?
~
>> > That approach strips down on application complexity. My apps don't have
>> > to do any post-processing
>>
>> of the data - I query the records I need and the app merely displays them.
>> ~
>>  Again have you actually tested those assumptions?
>
> Yes, I have, as have many others.  Simple example: program a website like,
> say
> Facebook. So you have thousands of users from all over the world. Your
> website
> code handles all the data conversions. Now Apple comes along and sells an
> iPhone which silly enough a lot of people like and try to use to access your
> website. You now face the problem that you need a second website doing the
> same thing as the first website except solely made for touch-screen devices.
> You will be forced to rewrite a lot of your code because all the data
> conversion is in the code.
~
 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
~
> Sure this all depends on what application you need this specialized database
> engine for. If it's an application for a very defined environment you can
> dictate how data is to be input and train users. If it's an application for
> the big wild world you will have problems with users doing stupid things
> beyond your control like writing "P.O. Box 1" into the zipcode field where
> you
> expected a 10 digit number. I rather have the database catch those cases and
> reject storing the bad input.
~
 You see this is just an implementation issue I would rather try to do
validation as close to the client as possible and do it in an
incremental way if necessary
~
On 9/25/11, Chris Travers <chris.travers@gmail.com> wrote:
> ...
> So here you get a case where the application was made less robust and
> performed quite a bit worse by not using arbitrary math capabilities
> of PostgreSQL.
~
 this example is not representing what we have been discussing here
and rounding/decimal representation is something base 2 arithmetic was
not design for anyway
~
 thank you and I think I will go for it anyway. Now, (and this is a
question for developers) since refactoring code is something that has
crossed your collective/cultural mind, is there a way I could do my
own perusing with the code that you would find useful?
~
 lbrtchx