Re: Size matters to some


Glen B wrote:
"dawn" <dawnwolthuis@xxxxxxxxx> wrote in message
news:1154092040.980665.107730@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx


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!

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 can play ball on either side of the team, but I love debates more than
just saying "Yes, I agree". This is especially true in regards to theories
and application of theories. Review this incomplete RFC if you want more
support material for CRUD in MV:

http://www.mvdevcentral.com/mv-rfc.txt

Then, put on your XML glasses and replace all of the raw ASCII
specifications with XML transactions. Either solution works without
specifying field size limitations. The underlying remote database connection
could be a Perl script that uses Postgres or a service written inside of MV.
The only difference there is the fact that when using MV, you won't have to
setup the database ahead of time. Write methods can create new items with
irrelevant field lengths. So, yes, I do agree in some situations.
Unforatenetly, some people here and outside of MV see this as weak, mainly
because the data store has no pre-conceived notions of what will be stored.
Is that bad? Well, that depends on the business environment. Strict data
storage policies may require something unlike MV, simply because it allows
you to put _anything_, of any length, in any field. Typed databases prevent
this to a fair extent by requiring type and size limitations to be assigned
when the database is designed and fields are created. Even though the
physical layer is actually managing it all, the logical layer is forced to
abide by the rules too. If you circumvent those rules by performing
inappropriate updates, then all you are doing is hurting the company and
more likely the database too.

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.

So you want to separate the integrity and validation layer from the data
storage layer?

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.

Have you considered performance implications?

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?

MV is fast,
compared to many databases, because it doesn't have to put each read and
write underneath a high powered magnifier.

Yes!

Your comments on the OpenQM
group, regarding integrity, were along the same lines. I still disagree,
mostly from a performance stand point.

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.

If you want a 10-piece SOA data
service, then I don't have a problem building one or even suggesting
technical or theoretical ways to do 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.

Don't expect a high-performance
database, though.

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?

Each single disconnection from the core inserts a
predictable amount of hardware resources and CPU time per transaction.

Yeah.

It's
bad enough having to pass each transaction through an in-core filter, much
less having to send that transaction off to a distant galaxy(remote server)
and wait for some sign of life to return(status code).

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


Thanks. --dawn


Glen

.

Relevant Pages

  • Re: OOP - a question about database access
    ... >> Why would a database be a good place to validate text from an ... Have it as a constraint defined in the database. ... I'd don't care how many tiers enforce integrity constraints of various ...
    (comp.object)
  • Re: [Info-Ingres] String Manipulations
    ... the BL layer of a SOA deployment but to do the same in the database ... I want my database tuned for retrieving data as quickly as ... this type of business logic and referential integrity and constraints. ...
    (comp.databases.ingres)
  • Re: Looking for a decent data access architecture to implement
    ... > application so that there is a clean separation between the data access ... > layer, the business layer and the GUI layer. ... > the actual database. ...
    (microsoft.public.dotnet.languages.csharp)
  • Looking for a decent data access architecture to implement
    ... application so that there is a clean separation between the data access ... layer, the business layer and the GUI layer. ... the actual database. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: "Business Objects" and the DAL
    ... layer talks to the layer next to it. ... business entity returned that up to the UI for binding to a grid. ... If a database table column names ... Each could be considered a "pattern", ...
    (microsoft.public.dotnet.framework.adonet)