Re: [phplib] default authentication, anyone using it? From: giancarlo pinerolo (giancarlo <email protected>)
Date: 08/06/01

Kristian Koehntopp wrote:
>
> 2. Name-Value tables
>
> Alternatively, require that all userdata items be of a specific
> type (for example, they must fit into a varchar(255) column.

The problem is that 255 may not be enough.

>
> >I don't deny the necessity of consolidated structures. But I
> >think that not to provide for provisional creation of
> >'unconsolidated', free form, fringes of information is an
> >error.
>
> This is in fact a question that touches aspects of design
> philosophy. I hope you don't mind if I explain my view of this.
>
...

> Application state is being used to accumulate data in free form
> from consolidated tables, like items are being collected in a
> shopping cart object that is part of the session. At some time
> the application has accumulated enough data or reached a certain
> internal state.
>

....

> Because that particular price is variable over time, you cannot
> just enter an article number into an order log, but you need to
> copy all critical data that may vary from the live tables into
> the session, and from the session into the order log. As a nice
> side effect, this lends itself to data warehouse design and star
> tables automatically, so that you can generate aggregates and

The problem is that is not only variable over time, but its price can
vary on the way from the shelf to the cashier.
'discounts on special offers will be applied at the cash' is written,
and it is truely so because if ther is a special offer for a bottle of
oil+frozen pizza, the price you'll pay for the oil changes at the moment
you pickup the pizza too.

>
> I believe that is what you were trying to explain with
> your rebate scheme and customer behaviour analysis
> example?
>

That of mine was a typical example, for how trivial it may be, of what
is mostly 'user profiling' needed for today on this vulgarized web
world: games, special offer campaigns, promotions, upsells etc..

These campaigns usually last short time, weeks, not even months. The
requisites and criteria vary: they depend normally on a variable mix of
time (when the campaign starts and ends), wthe actual user selections,
in relation with other selections or choices, membership status, amount
spent in all or at maximum ever, or in that particular visit, and other
typical wharehouse juice.
There are three issues here: canonicizing criteria, acquiring historical
information, storing activity data and cookies.

First of all, these criteria are difficult to canonicize and generalize,
you usually better solve them by coding than by trying to give them a
structural parametrized shape. This time it counts if you have played
game A, next time if you buy article B and C at the same time, and so
on...

And then there is the wharehouse information, that you need to make
available, not for everyone, but for those who need it, in almost
realtime, it must be available at every page_open, to be clear. So you
must regularly update the user data with an updated sumpt of what you
need to know, and carry it along.

This is the typical case where I'd prefer to keep the data close to
where it is needed, which in this case is the User data, rather than
have to go and search for it sparse over a net of records of everyone,
reachable very precisely, but at the cost of lengthy vertical
processing.

So in this case I'd invent a User container value, a structure that can
hold all what I need, only for those who need it. Vertical queries is
important, but that is something which is normally done in the back
office. You are not concerned about performance too much there. Where
performance matters is in the live use of this, and you cannot afford to
run vertical queries here.

So, as the whole thing are quite short lived, I find it very useful to
have the possibility to invent a temporary 'carnet', that will last the
life of the campaign, and that will live only in the user storage. Think
of this as a looong walk from the shelves to the cashier at the
supermarket...

At the end it all ends up in the big repository for analysis, but with
he time you save on creation and implementation you can start writing
those kinda 'vertical_except_the_fringes' analysis that will make the
boss happy meanwhile.

And when everything is over, you keep some cookie of what has been done
anyway, because it is handy to have it there, where you need it, and you
may never know what the next campaign will want to know... Retrieve
something that you know it exists is better anyway than go and look for
something that may or may not not exist.

And with ease and time I'll learn what is really worth to be stored
(they don't know), and if I see a benefit I'll extend everybody's user
preferences for that, and one day get rid of those old cookies left in
some User's bag.

These for me are the major benefits (I know somebody calls them caveats)
of having the possibility to invent data on-the-fly.

(Yes I am a beast. but the important is to make me understand...and food
is always a comprehensible argument ;-)

Giancarlo 

-- 
Abbestellen mit Mail an:   phplib-unsubscribe <email protected>
Kommandoliste mit Mail an: phplib-help <email protected>