Re: Updating only fields which users have changed
From: Jason (pmorrison_at_4lpi.com)
Date: 01/07/04
- Next message: dr. zoidberg: "Long URL breake my html"
- Previous message: knocte: "Re: Modify an array inside a foreach"
- In reply to: André Nęss: "Re: Updating only fields which users have changed"
- Next in thread: André Nęss: "Re: Updating only fields which users have changed"
- Reply: André Nęss: "Re: Updating only fields which users have changed"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 7 Jan 2004 11:34:26 -0800
André Nęss <andrena.spamreallysucks@ifi.uio.no> wrote in message news:<bth5t5$ko1$1@maud.ifi.uio.no>...
> Jason:
>
> > André Nęss <andrena.spamreallysucks@ifi.uio.no> wrote in message
> > news:<btf44q$e74$1@maud.ifi.uio.no>...
> >>
> >> I see no reason not to choose option 1. This is the simplest solution,
> >> and I can't see any problems with it. Do you? Seeing as you list the
> >> other two options I mean...
> >
> > Thanks everyone for the responses. I think I was a little too generic
> > in my original post. Right now I'm trying to write some classes for
> > updating a database. Sometimes users will be submitting a form that
> > has fields for one record in one table, but sometimes they will be
> > using a form with 30 or 40 rows of fields for 30 or 40 records.
> >
> > I understand in the first case that my option one (simply constructing
> > an UPDATE statement with all the fields) is the simplest, and that
> > building a UPDATE statement of only the fields that have actually
> > changed probably won't save much on the database end. But what about
> > the latter case, where there will be 30 or 40 UPDATE statements? In
> > many cases only 1 or 2 of the records may be changed at all, so if the
> > script only submits 1 or 2 UPDATEs instead of 30 or 40 there should be
> > some savings, right?
>
> Yes there will be savings, but I regard it to be a case of premature
> optimization, the update statements in question should finish fairly
> quickly. On the other hand if you can avoid the redundant updates without
> much extra code then I guess you might as well just go ahead and do it.
I get your point. I'm actually re-writing a bunch of poorly-organized
code so I'm trying to think ahead. There are other issues as well.
For example, if I'm already checking to see if a field has changed, I
don't need to validate any of the non-changing data that's submitted.
In general, do most people just run everything in $_POST through a
regular expression or something to look out for malicious entry? I
guess I'm really wonderring if what I'm saving by trimming UPDATES and
not validating unimportant data outweighs whatever cost there is to a
larger $_POST.
> > And here's another question. I've been thinking about the whole
> > separating business logic from presentation logic deal, and I've got
> > an idea but I'm not sure if I'm over thinking all of this.
> >
> > Let's say I have an entity called thing. I'll have a file called
> > thing.php which the users will actually call up in their browser,
> > usually following links like thing.php?action=view&thing_id=123 or
> > some such. Depending on the $_GET vars, thing.php will include
> > another file called thing_form.php, thing_view.php, thing_list.php,
> > etc., which has all the display logic and html they will see. It will
> > also include a file thing.inc.php which has a class with all the
> > functions and business logic for thing.
> >
> > Does this make sense, or am I pulling things apart too much? When
> > I've done little play pages in the past I've lumped all this stuff
> > together in one page, so will all the includes (at least two each time
> > a user goes to thing.php) slow everything down? Also, I'd be
> > interested in hearing how everyone likes to keep their
> > directories--lots of little, specific purpose files or a few large
> > files which do everything?
>
> Sounds quite similar to schemes I've been using. I generally have
> modularized systems (where a typical module is "user" or "document" or some
> other entity in the domain of discourse). Each module offers the normal
> CRUD (Create Read Update Delete) operations, and I usually have a handler
> or driver which takes care of the mapping from _GET variables to what
> should actually happen. How you do things from here depends on the
> complexity on your application. In general, start simple, and break things
> up on demand.
One more question, if it's not too much bother--do you find yourself
representing your database fields as a bunch of class variables or an
array or some such, or do you end up just using $_POST and the array
returned by the database? This seems to defeat the 3-tier-ishness a
little since adding a field requires updating the database and the
class, but I don't really see any way around it that I like. I don't
want to query the database for the table definition every time I
create a new instance of an object.
> File sizes and what you put in what file really don't matter that much if
> you ask me, the most important thing is that you have a well designed
> application with fairly small specialized functions that are composed
> properly and that have clear responsibilities. A good editor should make it
> simple to browse the code.
True. I'm just trying to wrap my head around some of the big-picture
stuff. I tend to think in terms of user needs and requirements,
interface and information design, etc. first and then write code that
does whatever I need it to do. I'm trying to think more in terms of
code organization and reusability, though, as I work on more projects.
Thanks.
- Next message: dr. zoidberg: "Long URL breake my html"
- Previous message: knocte: "Re: Modify an array inside a foreach"
- In reply to: André Nęss: "Re: Updating only fields which users have changed"
- Next in thread: André Nęss: "Re: Updating only fields which users have changed"
- Reply: André Nęss: "Re: Updating only fields which users have changed"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
