Blatant ad for my latest blog entry entitled "To Whom Should Size
Matter?"

http://www.tincat-group.com/mewsings

I hope it is a good read. Feel free to leave comments in the blog or
by e-mail (or even here). Cheers! --dawn

"dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote

The answer, of course, is to whom it may concern. BobJ

BobJ wrote:
That's all I get after pouring my heart and soul into it, Bob? I guess
when I pick titles like that, I deserve it, eh?

Other comments, particularly ones about the topic of the blog, would
also be welcome. Agree? Disagree? This should largely be an agreeing
crowd, I think, maybe, perhaps, while the relational crowd might have a
bone to pick (no pun intended on anything in that last phrase).
Cheers! --dawn

"dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote

BobJ

Glen B wrote:
Of course, but you can make block sizes or select a modulus oand put a
limit on the size of all values globally in a way that does not prompt
designers to identify a maximum first name length of 15 and last name
of 26 (or other somewhat arbitrary lengths). As we can clearly see,
there is no particular reason why individual attributes needs to be
specified to the DBMS tools with a maxlen specification, right?

Perhaps I should modify it to make it very clear that surely I know
that one must allocate computer resources somehow, I'm just opposed to
allocate them by requiring a maxlen on every attribute

? then there would be no
I predicted that I'd be told about the fact that computer resources
were not infinite, so I probably should have said something to stave
that criticism off. I might toss in a line.

I do find it curious that it would not be assumed that I comprehend
that point and appreciate you pointing it out because then I'll be
prepared for the "well, little girl, it's like this" responses ;-)

There is a still a size to a Pick data value even if there is no maxlen
defined for an attribute schema.

But it need not do it like a SQL-DBMS does -- it can do it like a Pick
database does, without the maxlen specification to the DBMS.

Even if field A should be 2 characters, I don't want to specify that
size to the DBMS -- it only increases how brittle the software is.

Precisely -- the DBMS, plus any paramters, tuning, file sizing,
overflow handling, etc that must happen need not depend on me telling
the DBMS how big a first name can be.

I take it that it does not sound to you like I am advocating for an
approach that functions from a developer & end-user perspective the way
that Pick does?? I'm not catching your point on this as it sounds like
you were not catching mine.

Yes!

Does a system designer/implementer physically define the size of fields
in Pick? We describe a display length in the dictionary, optionally,
but we do not put a maxlen on every attribute in every file, right?
Maybe I'm missing your point -- feel free to try to help me catch on.
Thanks. --dawn

Glen B wrote:

I(1) think(5) this(4) might(4) be(2) a(1) better(6) response(8) to(2)
this(4) type(4) of(2) comment(7),(1) perhaps(7)?(1)

--dawn
P.S. Does that make my point clearer or not? (again, I appreciate you
preparing me for others who I suspect would share your response).

"dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote

What about white space.

Not really. Actually, reviewing your point there makes things even more
complicated. Consider a client that needs to talk UTF-8 and ASCII for
different data stores. The storage sizes are completely different!

Glen

Glen B wrote:
We will just consider them delimiters :-)

Yes, but you need to pop up a level or two in network layers to the
logical and implementation specifications from a developer. Is it
necessary or even good for development teams to specify maximum length
constraints to the DBMS? We don't have to do it in Pick, right? So it
clearly isn't necessary.

I'm most interested in learning how I can make the point I'm trying to
make and still have people who think like you do, Glen, at what we
might call a more technical level, closer to the machine, understand
what my point is and maybe even track with the argument enough to see
that it might be a good point. If someone who knows and understands
Pick doesn't see my point, you can imagine how hard it would be for
someone who has only known DBMS's that require and enforce maxlen
constraints as specified by developers. So, any clues you can give on
whether you understand my point and how I can say it so that you would
have understood it right away, are most welcome.

Thanks. --dawn

Glen B wrote:
Maybe I'm not saying it properly. I want to be able to validate a data
element, such as an attribute that must be an integer between 4 and 30,
let's say separate from writing the record that includes this
attribute. No one using Pick does otherwise. Additionally, I still do
want to validate the information getting written. In the case of green
screens and their ilk, this can be done with validation at the time of
data entry and then we know we have a good value and can write it. In
the case of a rich browser UI, for example, we can validate at the time
of data entry, but someone might greasemonkey the data, for example,
and what comes into the back-end might need to be re-validated. If the
services that write data also validate it (yet again), that is better
than if the DBMS revalidates it -- it is a more flexible approach in
that this service can use whatever the UI uses for validation specs
(perhaps). If there is no need for a revalidation, then surely don't
do it. My interest is in bumping up the validation to the layer above
the DBMS for a number of reasons.

This is what we do with MV -- we validate above the layer of the DBMS.
Does that degrade performance? No, I would think it improves it,
right? We are still speaking different languages and I'm really
interested in learning yours, so keep talking -- what do you mean and
what do you think I mean?

Yes!

This is such an unbelievably perplexing statement to me. So, you think
that it is better for performance to have the constraint handling, such
as type, size, range, lookup table, etc testing done in a way that is
tightly coupled with the database writes rather than in the layer above
it? So, even if an application knows that the data are completely
compliant with the constraints, they must be reapplied in the write? I
really, really want to understand your point and am clearly clueless
about it.

I have no idea where that is coming from. I'm not looking for a big
thing, just something that both accomodates the need for integrity and
the need for flexibility. We have that with Pick by NOT coupling
logical database constraints (such as your average, everyday data
validations) with the writes.

I'm not asking for something that I can't see today. Are you planning
to increase the speed of Pick by tightly coupling constraint handling
and database writes?

Yeah.

WOW -- I never even considered doing anything remotely like that. I
wish I knew which words triggered this type of thinking. I my use of
the term service in the way it was used before SOAP got in the picture
is now making you think I'm looking for SOAP services when I just want
subrs/functions, then maybe that is what is causing the disconnect.
Hmmm. I'll re-read what I wrote and maybe instead of using the more
human term of "service" I should just use the term "function" or so?
Still perplexed, but this last sentence at least gave me some more
clues on what the words I'm typing mean to you compared to what they
mean to me. thanks a bunch. --dawn

dawn wrote:
I'm not really sure where or if this fits in with the discussion here
but...

In the early stages of development of what was to become ASPick (a web
development framework for Pick), and formed the core of the web
application for the web-site Hill House Hammond used to sell insurance
on the net, a colleague wondered what would happen if he just kept his
finger on a key for a very long time, entering an enormous string into
a text field on the browser.

I can't remember if it actually broke the app or not. I know the
PickBasic would have handled it. I know there wouldn't have been a
problem writing and reading it. I just realised I would have to build
something into the framework to prevent that sort of thing from being
allowed to happen.

I didn't even consider putting the constraint in a CALLX or anything at
that level. It had to be prevented from happenning at source as soon as
it hit the application driver program. I decided the best thing to do
was make the framework generating the HTML force a maxlen property for
every text (and similar) field. Then, as always, I had to build the
same validation into the framework driver (ASPick itself).

I took the view then that no matter what validation was being done on
the browser, every single datum had to be rechecked, *more* rigorously
than what the javascript was able to check at the client end, before
the application framework did anything else with it - as soon as it was
extracted from the name/value pair list. This is a "belt and braces"
approach, but it really *must* be done, imnsho, when writing apps for
the web. <aside>One of the beauties of having a single "master" or
"driving" program is that it is easily extensible in this way. One
change applies at once to everything.</aside> Who knows whether the
name/value pair list actually originated from your browser app or
whether some hacker is sending a name/value pair list they've
constructed themselves to try and fool your server?

So - size constraints are necessary on the client, and they're
necessary in the DBMS too. That driver program I mentioned is, of
course, within the DBMS.

Regards,
Mike.