php-windows Digest 18 Oct 2004 14:32:18 -0000 Issue 2432
Topics (messages 24763 through 24774):
Re: PHP & Win98
24763 by: Gryffyn, Trevor
Church Database
24764 by: Chris Ollar
24765 by: Gryffyn, Trevor
24766 by: Wagner, Aaron
24767 by: George Valenzuela
24768 by: Felipe Gasper
24770 by: Gryffyn, Trevor
Download pages
24769 by: Dylan Barber
zlib html compression
24771 by: David Hamilton
24773 by: Manuel Lemos
My brain hurts....
24772 by: Chris Ollar
PHP 4, IIS cookie problems with non-standard port.
24774 by: David Priebe
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
--- Begin Message ---
Yup! Just check out the PWS/IIS instructions in the manual:
http://www.php.net/manual/en/install.windows.iis.php
> -----Original Message-----
> From: Chris Ollar [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 15, 2004 10:02 AM
> To: [EMAIL PROTECTED]
> Subject: [PHP-WIN] PHP & Win98
>
>
> Will PHP attach to Win98 Personal Web Server?
> Thanks to all who respond -
> Chris
>
> --
> PHP Windows Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
I realize this is asking a bunch but here we go...
The local church I belong to wants to implement a web based database so that
we can track attendance of our various groups that meet outside the church.
We want our group leaders to be able to add/delete/modify names and contact
information for their particular group members .
We want to be able to enter attendance information for each member on a
weekly basis.
We want to be able to track attendance history for each member so that we
can contact folks who might have stopped coming to their group.
The church has about 2000 members. The groups can range in membership from
as few as 5 to as many as 300.
I'm a novice programmer and was looking into using MySQL and PHP to
implement the system.
Am I on the right track?
Any thoughts or suggestions?
Me being a beginner am I going to eat up to much time on my learning curve?
Would I be better off paying someone to do this?
Project wise is this a small, medium, or large undertaking.
Thanks to all who respond!
Chris Ollar
--- End Message ---
--- Begin Message ---
> The church has about 2000 members. The groups can range in
> membership from
> as few as 5 to as many as 300.
>
> I'm a novice programmer and was looking into using MySQL and PHP to
> implement the system.
>
> Am I on the right track?
> Any thoughts or suggestions?
> Me being a beginner am I going to eat up to much time on my
> learning curve?
> Would I be better off paying someone to do this?
> Project wise is this a small, medium, or large undertaking.
No actually this is a great beginner project because it's not too
difficult.
First thing you want to consider is your database structure. Sounds
like you have members, groups, and dates of attendance. I'm not a DBA
or expert databse programmer, but this is how I'd organize things.
(use your preferred naming convention.. For instance, I'd called the
Memberships something like "xrefUsersGroups")
Table 1: Users
This contains all your user information. The first column in most
database tables (there are exceptions) should always be a primary key
that's automatically incremented each time a record is added. This
creates a unique identifier for each record. I forget what they call it
in MySQL, maybe AutoNumber (on an INT or INTEGER data type). In MS SQL
Server they call it "identity".
Columns recommended:
UsersID
Name
Address
Phone
etc...
Table 2: Groups
This is where you hold some basic (or detailed) information about the
groups that meet. Same deal with the identity/autonumber column
Columns recommended:
GroupsID
GroupName
GroupLeader
MeetingLocation (might be another ID field that points to a
locations table.. Or locatio may be stored on a date by date basis if it
is possible that it moves)
Table 3: Memberships
This is a cross ref table that you store the identity/autonum values
for a user and a single group that they below to. There will be
multiple entries if a user is in multiple groups. This probably only
needs to consist of 3 columns: ID (identity/autonum), UserID, GroupID
Columns recommended:
MembershipsID
UsersID
GroupsID
Table 4: Attendance
After your identity/autonumber ID field, you'd want a date, groupid
and userid. You could have other info too like Topic of the meeting or
guest speaker info or whatever. If you get too much info, you might
want to store it in another table with a link back to the identity
column of this table
Columsn Recommended:
AttendanceID
Date
UsersID
GroupsID
Depending on how anal you are about normalization, you might have an
xref table that links groups and users with attendance and only have
meeting date and location (and other such unique data) in the Attendance
or maybe a "Meetings" table.
>From there, you just need to learn how to do some SQL to join the tables
in order to retrieve the data.
The other things on your task list would be:
1. Create an interface
2. Learn how to insert data into the database (keeping all the tables
straight)
3. Probably learn how to import an existing list of your 2000 members
into the database to save you some typing
4. Create reports based on the data you pull showing "last attended this
group" for each user and flag it if it's over a certain amount of time.
You'll find some good guideance on these groups (you might check out the
PHP DB one for the database questions, but I'm sure someone on here
could help as well).
Anyway, hope that gives you an idea of what you're getting into. It's
really not all that bad, but it'll be a challenge for a newbie :) A
good challenge though, not one of those TOO frustrating ones.. Heh
Good luck!
-TG
--- End Message ---
--- Begin Message ---
> I'm a novice programmer and was looking into using MySQL and PHP to
> implement the system.
> Am I on the right track?
> Any thoughts or suggestions?
That's a good start. If you also put it on an Apache Server
it will all be free as they are all Open Source = Free.
> Me being a beginner am I going to eat up to much time on my
learning curve?
That's hard to answer, PHP, Apache, and MySQL have GREAT
documentation websites for learning. I program in PHP all
day so it's easy for me, but there is a slight learning curve.
> Would I be better off paying someone to do this?
Depends on the situation. Would you be willing to take the
time to learn and donate your time? Does the church need
this quickly? On the flip side, If you write the code you
will be familiar and can update and fix it later for the church.
> Project wise is this a small, medium, or large undertaking.
I'd say Medium because of your learning curve. The code
itself is pretty reusable and small. Your basically adding
data to a DB and retrieving it, no heavy processing.
aaron wagner
> -----Original Message-----
> From: Chris Ollar [mailto:[EMAIL PROTECTED]
> > Sent: October 15, 2004 10:51
> > To: [EMAIL PROTECTED]
> > Subject: [PHP-WIN] Church Database
> >
> >
> > I realize this is asking a bunch but here we go...
> >
> > The local church I belong to wants to implement a web based
> > database so that
> > we can track attendance of our various groups that meet
> > outside the church.
> >
> > We want our group leaders to be able to add/delete/modify
> > names and contact
> > information for their particular group members .
> >
> > We want to be able to enter attendance information for each
> > member on a
> > weekly basis.
> >
> > We want to be able to track attendance history for each
> > member so that we
> > can contact folks who might have stopped coming to their group.
> >
> > The church has about 2000 members. The groups can range in
> > membership from
> > as few as 5 to as many as 300.
> >
> > I'm a novice programmer and was looking into using MySQL and PHP to
> > implement the system.
> >
> > Am I on the right track?
> > Any thoughts or suggestions?
> > Me being a beginner am I going to eat up to much time on my
> > learning curve?
> > Would I be better off paying someone to do this?
> > Project wise is this a small, medium, or large undertaking.
> >
> > Thanks to all who respond!
> >
> > Chris Ollar
> >
> > --
> > PHP Windows Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
--- End Message ---
--- Begin Message ---
Just to throw my two cents in, having done a small-ish project for a
local soccer league, PHP website with a MySQL backend, it was a very
manageable learning curve, particularly since I had web experience on
Windows with ASP, but nothing out of this world.
The experience was very valuable and I've gone on to appreciate open
source a lot more now!
On Fri, 15 Oct 2004 11:15:43 -0400, Wagner, Aaron
<[EMAIL PROTECTED]> wrote:
>
>
> > I'm a novice programmer and was looking into using MySQL and PHP to
> > implement the system.
> > Am I on the right track?
> > Any thoughts or suggestions?
> That's a good start. If you also put it on an Apache Server
> it will all be free as they are all Open Source = Free.
>
> > Me being a beginner am I going to eat up to much time on my
> learning curve?
> That's hard to answer, PHP, Apache, and MySQL have GREAT
> documentation websites for learning. I program in PHP all
> day so it's easy for me, but there is a slight learning curve.
>
> > Would I be better off paying someone to do this?
> Depends on the situation. Would you be willing to take the
> time to learn and donate your time? Does the church need
> this quickly? On the flip side, If you write the code you
> will be familiar and can update and fix it later for the church.
>
> > Project wise is this a small, medium, or large undertaking.
> I'd say Medium because of your learning curve. The code
> itself is pretty reusable and small. Your basically adding
> data to a DB and retrieving it, no heavy processing.
>
> aaron wagner
>
>
>
> > -----Original Message-----
> > From: Chris Ollar [mailto:[EMAIL PROTECTED]
> > > Sent: October 15, 2004 10:51
> > > To: [EMAIL PROTECTED]
> > > Subject: [PHP-WIN] Church Database
> > >
> > >
> > > I realize this is asking a bunch but here we go...
> > >
> > > The local church I belong to wants to implement a web based
> > > database so that
> > > we can track attendance of our various groups that meet
> > > outside the church.
> > >
> > > We want our group leaders to be able to add/delete/modify
> > > names and contact
> > > information for their particular group members .
> > >
> > > We want to be able to enter attendance information for each
> > > member on a
> > > weekly basis.
> > >
> > > We want to be able to track attendance history for each
> > > member so that we
> > > can contact folks who might have stopped coming to their group.
> > >
> > > The church has about 2000 members. The groups can range in
> > > membership from
> > > as few as 5 to as many as 300.
> > >
> > > I'm a novice programmer and was looking into using MySQL and PHP to
> > > implement the system.
> > >
> > > Am I on the right track?
> > > Any thoughts or suggestions?
> > > Me being a beginner am I going to eat up to much time on my
> > > learning curve?
> > > Would I be better off paying someone to do this?
> > > Project wise is this a small, medium, or large undertaking.
> > >
> > > Thanks to all who respond!
> > >
> > > Chris Ollar
> > >
> > > --
> > > PHP Windows Mailing List (http://www.php.net/)
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > >
> >
>
> --
> PHP Windows Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
[EMAIL PROTECTED]
Google Much?
--- End Message ---
--- Begin Message ---
A few comments on Trevor's DB structure recommendations regarding
primary keys.
1) Only make the auto-incrementing primary key IF you don't already have
a unique identifier for each item in the table. Your church probably
doesn't have existing unique IDs for each member (or maybe you do -
membership #?), so that's ok for the "users" table. For "groups",
though, presumably you don't have two groups both called simply "choir",
so you might as well make the group name the primary key there.
2) Along the same line, I'd say you don't need an auto-incrementer in
the "memberships" table. What you do there is make the primary key span
two columns, which tells MySQL that each user/group pair must be unique.
3) I fail to see why the "attendance" table needs a primary key at all.
As a general rule, I say a table only should get a primary key if
something in there, be it a single column or combination of columns,
must be unique in each row. Otherwise your tables are storing data that
isn't used.
You might also consider removing the "memberships" table entirely in
favor of a comma-separated BLOB field "memberships" in the "users"
table; MySQL's FIND_IN_SET function works well to process data like that
in queries. The upshot is that you're reducing table size (I think) and
making it easier to make a list of members that users belong to, since
MySQL 4.1, with its GROUP_CONCAT function, isn't released yet. The
downside is that it's not quite as "pure" a data layout, and there
probably are portability concerns as well. Of course, were you using
Postgres, you could just make an array-typed column. ;-)
Just my $.02; the rest of the suggestions look fine to me.
-Felipe Gasper
Quoth Gryffyn, Trevor on 10/15/2004 11:10 AM...
Table 1: Users
This contains all your user information. The first column in most
database tables (there are exceptions) should always be a primary key
that's automatically incremented each time a record is added. This
creates a unique identifier for each record. I forget what they call it
in MySQL, maybe AutoNumber (on an INT or INTEGER data type). In MS SQL
Server they call it "identity".
Columns recommended:
UsersID
Name
Address
Phone
etc...
Table 2: Groups
This is where you hold some basic (or detailed) information about the
groups that meet. Same deal with the identity/autonumber column
Columns recommended:
GroupsID
GroupName
GroupLeader
MeetingLocation (might be another ID field that points to a
locations table.. Or locatio may be stored on a date by date basis if it
is possible that it moves)
Table 3: Memberships
This is a cross ref table that you store the identity/autonum values
for a user and a single group that they below to. There will be
multiple entries if a user is in multiple groups. This probably only
needs to consist of 3 columns: ID (identity/autonum), UserID, GroupID
Columns recommended:
MembershipsID
UsersID
GroupsID
Table 4: Attendance
After your identity/autonumber ID field, you'd want a date, groupid
and userid. You could have other info too like Topic of the meeting or
guest speaker info or whatever. If you get too much info, you might
want to store it in another table with a link back to the identity
column of this table
Columsn Recommended:
AttendanceID
Date
UsersID
GroupsID
Depending on how anal you are about normalization, you might have an
xref table that links groups and users with attendance and only have
meeting date and location (and other such unique data) in the Attendance
or maybe a "Meetings" table.
From there, you just need to learn how to do some SQL to join the tables
in order to retrieve the data.
The other things on your task list would be:
1. Create an interface
2. Learn how to insert data into the database (keeping all the tables
straight)
3. Probably learn how to import an existing list of your 2000 members
into the database to save you some typing
4. Create reports based on the data you pull showing "last attended this
group" for each user and flag it if it's over a certain amount of time.
You'll find some good guideance on these groups (you might check out the
PHP DB one for the database questions, but I'm sure someone on here
could help as well).
Anyway, hope that gives you an idea of what you're getting into. It's
really not all that bad, but it'll be a challenge for a newbie :) A
good challenge though, not one of those TOO frustrating ones.. Heh
Good luck!
-TG
--
Quidquid latine scriptum sit altum viditur.
Si hoc legere scis, nimis eruditionis habes.
Easier web browsing: http://mozilla.org
--- End Message ---
--- Begin Message ---
I know there are a million schools of thought on design structure, so
I'm not trying to argue here, but I'd like to make some comments.
> A few comments on Trevor's DB structure recommendations regarding
> primary keys.
>
> 1) Only make the auto-incrementing primary key IF you don't
> already have
> a unique identifier for each item in the table. Your church probably
> doesn't have existing unique IDs for each member (or maybe you do -
> membership #?), so that's ok for the "users" table. For "groups",
> though, presumably you don't have two groups both called
> simply "choir",
> so you might as well make the group name the primary key there.
I never assume that users (if they have a hand in naming things like
membership groups) will NOT pick something that's duplicate. Using an
ID column removes all doubt. Plus, for doing the cross ref with the
users who belong to that group, I'd rather have a couple of numbers
stored than a string (potentially long) of the group name.
> 2) Along the same line, I'd say you don't need an auto-incrementer in
> the "memberships" table. What you do there is make the
> primary key span two columns, which tells MySQL that each user/group
pair must
> be unique.
This is a valid point. I'm not used to doing multi-column primary keys,
but I understand the idea. Thanks for mentioning it. You should never
end up with a member being in the same group twice, so this should work
out ok.
My only concern (and this would be more of a concern if you were dealing
with more than a few thousand rows of data) is that when you reference
the table, concatenation functions to compare the columns as a single
unit usually slow down a process quite a bit.
For example, we deal with truckers and airline freight where I work
(air-cargo-inc.com.. Obvious eh?) and one thing we deal with are
AirWaybills (AWBs). They consist of a three digit airline code ("057"
for Air France, etc) and an 8 digit serial number for that AWB. So they
might look like "057-01234567". In most of our databases, it's stored
like that. In one, it's stored as AirlinePrefix and SerialNumber. So
to compare a regular table's "057-01234567" with "057" and "01234567"
you'd need to do "WHERE t1.AWB =
t2.AirlinePrefix+'-'+t2.SerialNumber" which can produce a fairly slow
query with the amount of data we have in our system.
In that case, we don't really have a choice until we get our DBA to
re-engineer everything.
After all that babble, I do have to say that that's not really a concern
in this case because you're not dealing with that many people and saying
"DELETE FROM SomeTable where MemberID = 6 and GroupID = 3" isn't that
hard.
So, point stands. Using the member id and the group id should work
great for a primary key.
> 3) I fail to see why the "attendance" table needs a primary
> key at all.
>
> As a general rule, I say a table only should get a primary key if
> something in there, be it a single column or combination of columns,
> must be unique in each row. Otherwise your tables are storing
> data that isn't used.
I like using an autonum/identity column in most of my tables (except
xref type tables, they usually don't need it.. As mentioned above)
because it makes it easier to pull out the EXACT record (mostly for
things like DELETEing and UPDATEing... Or if you need to do something to
the record right after it's INSERTed like have a trigger make an entry
into an xref table.. Then you'd want to snag the newly created ID).
If there's an autonum column where it's impossible, due to database
rules and restrictions, to have duplicates, it removes all doubt for me.
And when you're talking about 2000 members, the overhead of an autonum
column is pretty negligible I think.
> You might also consider removing the "memberships" table entirely in
> favor of a comma-separated BLOB field "memberships" in the "users"
> table; MySQL's FIND_IN_SET function works well to process
> data like that in queries. The upshot is that you're reducing
> table size (I think) and making it easier to make a list of members
> that users belong to, since MySQL 4.1, with its GROUP_CONCAT function,
> isn't released yet. The downside is that it's not quite as "pure" a
> data layout, and there probably are portability concerns as well.
> Of course, were you using Postgres, you could just make an array-typed
> column. ;-)
Hah.. Well, that's the problem sometimes with these great functions.
You use them, get used to them, then move to another DB system and
you're like "uhh.. How come this doesn't work anymore?" I'm not
totally a purist about things, but I believe in reducing headaches or
potential headaches. To me, having the Memberships xref table is my
preferred way of tackling this one because it should be happy in any DB
system. Most DBs have some kind of strstr type function to find things
within a string in a datdabase field, but those kind of operations can
be slow and it means figuring out what commands work with what DBs.
Select u.Username,g.GroupName
>From Users u, Groups g, xrefUsersGroups xr
Where u.UserID = xr.UserID
And xr.GroupsID = g.GroupsID
And u.Username = 'Trevor Gryffyn'
Real simple.. Works both ways too:
Select g.Groupname,u.Username
>From Users u, Groups g, xrefUsersGroups xr
Where u.UserID = xr.UserID
And xr.GroupsID = g.GroupsID
And g.GroupName = 'PHP Users'
> Just my $.02; the rest of the suggestions look fine to me.
I see your $.02 and raise you a nickel :)
Good thoughts though, it's always good to have options and know what
they are. Thanks for posting, Felipe. I disagree for the above
reasons, but a lot of this is personal preference. If he's never going
to use anything but MySQL, then there's definitely no harm in leaning on
functions specific to MySQL. I end up using many different kinds of
databases, so I try to keep my practices a little more universal (so I
don't cause myself headaches), but that's my style. Your ways work just
as good.
You could have just one big table with a column that just had a list of
groups the user was in:
"Trevor Gryffyn", "PHP Users, DB Nazis, Mazda Drivers", "Etc"
And that'd work just fine too. It's not generally considered "good
database practice" and may be more cumbersome to manage than "better"
ways, but you could still make it work.
Anyone else want to chime in? Haha..
I never went to school for any of this, I'm all self-taught. So
sometimes my ways are goofy but I always try to learn and improve. If
I'm being goofy, forgive me. Hah
-TG
--- End Message ---
--- Begin Message ---
I have a page that checks a database and if the person is authorized it allows a
download. This works fine and dandy but the problem is it seems to freeze the browser
while it is downloading the file.
Has anybody had to deal with something like that?
<a href="mailto:[EMAIL PROTECTED]">Dylan Barber</a>
Webmaster / Web Developer / Programing
<a href="http://codegalaxy.com";>-codegalaxy.com-</a>
<a href="http://summer-swim.com";>-summer-swim.com-</a>
<a href="http://clipurl.com";>-clipurl.com-</a>
--- End Message ---
--- Begin Message ---
Hello all,
I'm currently re-designing my company's website. One of our major
concerns is load time. I happened to stumble across some information on
using zlib to compress pages using PHP.
The advice seemed "to good to be true" the recommendation was setup an
.htaccess file with the following:
php_flag zlib.output_compression on
php_value zlib.output_compression_level 6
It was my understanding this turns on output compression meaning that
any page parsed any ".php" (or any other extension associated with php)
will have its contents compressed if the requesting browser supports
HTTP 1.1
Is this correct? If not can anyone point in the proper direction of
doing this? I'm mainly interested in compressing a few key pages and a
somewhat bloated .js file (which I realize the method above wouldn't do
unless I ask to the server to parse .js as PHP...probably not a good
idea...)
Any help/comments/suggestions would be greatly appreciated.
Thanks,
David Hamilton
--- End Message ---
--- Begin Message ---
Hello,
On 10/15/2004 06:22 PM, David Hamilton wrote:
I'm currently re-designing my company's website. One of our major
concerns is load time. I happened to stumble across some information on
using zlib to compress pages using PHP.
The advice seemed "to good to be true" the recommendation was setup an
.htaccess file with the following:
php_flag zlib.output_compression on
php_value zlib.output_compression_level 6
It was my understanding this turns on output compression meaning that
any page parsed any ".php" (or any other extension associated with php)
will have its contents compressed if the requesting browser supports
HTTP 1.1
Is this correct? If not can anyone point in the proper direction of
doing this? I'm mainly interested in compressing a few key pages and a
somewhat bloated .js file (which I realize the method above wouldn't do
unless I ask to the server to parse .js as PHP...probably not a good
idea...)
In theory yes, it will compress the pages served by PHP to browsers that
support it. In practice, there are a few problems that advise to not use
the current PHP functionality, and use instead mod_gzip if you use
Apache 1.x because it comes with special workarounds for situations of
browsers that do not conform to the standards and other things like
proxies that should not be caching compressed responses.
Furthermore, mod_gzip will also compress HTML pages not generated by PHP.
I think Apache 2.x comes with built-in compression filter but I have not
tried it because several PHP extensions are not ready to work in Apache
multi-threaded mode, which AFAIK is the main advantage of using Apache
2.x instead of other Apache 1.x.
http://www.schroepl.net/projekte/mod_gzip/
--
Regards,
Manuel Lemos
PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/
PHP Reviews - Reviews of PHP books and other products
http://www.phpclasses.org/reviews/
Metastorage - Data object relational mapping layer generator
http://www.meta-language.net/metastorage.html
--- End Message ---
--- Begin Message ---
OK people....
First I want to thank Everyone who posted or sent mail. What a great
response! I see I have found a valuable resource. I am certain that many
questions will follow. Again, thank you all and I want to let you know that
I'm going to tackle this one on my own... with you peoples help of course.
I'm going to stick with MySQL and PHP for now. They look like solid choices
and I believe they'll do what I want.
newbie Chris
--- End Message ---
--- Begin Message ---
I have PHP 4, with IIS.
The server also has First Class (mail server with it's own web server)
running that must sit on port 80, so IIS is sitting on port 803. PHP seems
to be working fine, but I have an online auction software that I've
installed that is having a problem setting a cookie which I believe is used
for log-in status. I'd limit IIS to a separate IP address, but that won't
work because First Class will sit on all IP's, and all interfaces. So that
my users don't have to worry about a non-standard port, I set my proxy
server to look for a specific name (auction.domain.name) on port 80, and
redirect the traffic to port 803 on my IIS server(domain.name:803). With
that in mind however, I'm also testing using domain.name:803 for testing.
It looks like the author of the auction software is using standard php
variables for setting up the cookie, so I'm wondering if I can fool php to
think that it's sitting on port 80 since that's what the browser will see.
Now I used to be a programmer at one time, but I don't know anything about
php. I'm wondering if set-cookie with a variable HTTP_HOST may be where the
problem is.
Anyone have any ideas?
Thanks,
David
--- End Message ---
