Jeff 'japhy' Pinyan wrote:
On Jul 13, Scott R. Godin said:
http://www.webdragon.net/miscel/DB.pm
I'll check it out.
All Subscriber::DB objects would share the DBI object -- there's no
need for a billion database handles.
ok, so possibly one should do it differently than I have, in my example.
Well, look at it this way: either the Subscriber::DB object holds the
database, or it holds a subscriber. Choose.
If it holds the database, then it needs a method to lookup, create, and
return a Subscriber object from the database.
If it holds the subscriber, it needs to CALL the database to populate
itself.
Normally by this time I've been able to 'envision' the finished product
entirely, and it's just a matter of breaking it into smaller steps,
coding them, and glueing them together. That hasn't been the case with
this project.
Perhaps if I back up a bit and fill in some of the surrounding tasks, it
will make things clearer for you, and enable you to help make them
clearer for me. :-)
But what I had thought of doing would be to populate the object via
the database and fill it entire, thus being able to call any of the
Subscriber methods on it without generating multiple calls to the
database for each one.
Ah, so by "object persistence" you mean that you want to create the
objects from the state they had in the database, and then when you're
done with them, save them back to the database? That seems reasonable,
if you're not going to have multiple processes accessing and changing
this information.
The way I envisioned it was very similar to a tie() mechanism. Every
access or setting of a value triggers a database action. Your method is
certainly less of a strain on the database.
I had initially thought of some sort of tie-ing myself but realized I'd
be putting a bit of a strain on the database in some instances.. it
*may* not be a factor though, depending on how it will ultimately get used.
The goals here are:
o online database of subscribers (prefer email/snailmail for
receiving regular newsletters and coupons), with optional
birthday/anniversary for receiving special coupons.
o some sort of mailing list (possibly Mail::SimpleList) to send the
e-mails out.
o method for the user to change their own data (possibly thru
generation of unique URL's)
o methods of administration
* make individual changes to user data
* generate a csv-style snapshot of the db or (sections of the db
for snailmailings)
* methods for generating individualized template-driven
coupons/mailings to the list of subscribers.
* remove users from the list on request.
With that in mind, the dataflow I had imagined would be:
I.
1. Subscriber signs up to the list online (or fills out card manually
and someone else does data-entry)
1a. online form accepts data, taint-checks it, error-checks it, and
inserts it into the db
2. if we have their e-mail, send a welcome message on entry.
(MIME::Lite, or Mail::Mailer, et.al.)
3. once per day, an advance mailing is generated (via cronjob) for
pending birthdays and anniversaries), preferably somehow personalized
with data from the database.
4. regular mailings get sent periodically, again preferably somehow
personalized.
II.
1. User moves and wants to change their address/phone/email
HOW do we enable this for them so as to require as little admin
intervention as possible?
2. User's email bounces.
HOW to handle?
3. User wishes to permanently unsubscribe.
Again preferring to do this without admin intervention.
So, there will be instances where only one user will be handled, and
instances where we'll be sifting through all the users for specific data
(email, snailmail, birthday, anniversary)
I'm leaning towards (per your comments above) the Subscriber::DB holding
the database, with methods to create, lookup and return, alter, and
delete a Subscriber (object), which can then use the methods in
Subscriber to format its internal data however I need it, (possibly as I
cycle through a LIST of returned Subscribers, depending on the lookup
request)
Does it sound like I'm looking in the right directions ?
[remainder snipped for later follow-up]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
