Newbie help

Hello,

I am new to working with PHP and MySQL so I'm sure my mistake(s) are simple
enough. Basically, I'm trying to write a script(s) to add a row to a MySQL
database. I took the scripts below off a website and have been trying to
tweak them to do what i want. Unfortunately, the script usually gives me an
error message (the one defined in the script) and very occassionally inserts
a blank row in the database.

Any clues or advice on what I am doing wrong would be greatly appreciated.
Unfortunately, I have not found the solution on the web or MySQL site
(probably because I have no idea what I'm doing).

Thanks!

- Ken

RE: Newbie help

ken, it looks like there's a problem with this section of code

[CODE]
//Assign contents of form to variables
#$userid = $_POST['userid'];
#$passwd = $_POST['passwd'];

$sql = "INSERT INTO users (userid, passwd) VALUES (userid = 'userid',
passwd = 'passwd')";

[/CODE]

i'd recommend one of two things:

1 - uncomment out the assignment of the POST variables, and change your sql
statement to this:
$sql = "INSERT INTO users(userid,passwd) VALUES ('$userid','$passwd')";

2 - forego use of the assignment to variables, and plug the POST variables
directly into the sql statement instead.

in either event, i would recommend printing out the statement to the screen
so that you can be sure that the sql syntax is correct, and comment out the
insert command. when you're sure the syntax is correct, remove the print
statement and uncomment the insert command.

hope this helps

green


-----Original Message-----
From: Ken Larkman [mailto:admin@adept-hosting.net]
Sent: Wednesday, May 07, 2003 12:31 AM
To: Php-DB (E-mail)
Subject: [PHP-DB] Newbie help


Hello,

I am new to working with PHP and MySQL so I'm sure my mistake(s) are simple
enough. Basically, I'm trying to write a script(s) to add a row to a MySQL
database. I took the scripts below off a website and have been trying to
tweak them to do what i want. Unfortunately, the script usually gives me an
error message (the one defined in the script) and very occassionally inserts
a blank row in the database.

Any clues or advice on what I am doing wrong would be greatly appreciated.
Unfortunately, I have not found the solution on the web or MySQL site
(probably because I have no idea what I'm doing).

Thanks!

- Ken

Re: Newbie help

See below.


>//Assign contents of form to variables
>#$userid = $_POST['userid'];
>#$passwd = $_POST['passwd'];

Uncomment these lines - that's why your variables are blank.


>$sql = "INSERT INTO users (userid, passwd) VALUES (userid = 'userid',
>passwd = 'passwd')";

You can also write this as follows:

>$sql = "INSERT INTO users (userid, passwd) VALUES ('userid',
>'passwd')";

But I don't know if the way you have it should work or would cause an error.

HTH,

-Lisi


--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Newbie help

> 2 - forego use of the assignment to variables, and plug the POST variables
> directly into the sql statement instead.

This is even easier if register_globals = On. Such a setup just eliminates the
middle man.

Edward Dudlik
Becoming Digital
www.becomingdigital.com


----- Original Message -----
From: "Andy Green" <_agreen@bellsouth.net>
To: ; "Php-DB (E-mail)"
Sent: Wednesday, 07 May, 2003 00:43
Subject: RE: [PHP-DB] Newbie help


ken, it looks like there's a problem with this section of code

[CODE]
//Assign contents of form to variables
#$userid = $_POST['userid'];
#$passwd = $_POST['passwd'];

$sql = "INSERT INTO users (userid, passwd) VALUES (userid = 'userid',
passwd = 'passwd')";

[/CODE]

i'd recommend one of two things:

1 - uncomment out the assignment of the POST variables, and change your sql
statement to this:
$sql = "INSERT INTO users(userid,passwd) VALUES ('$userid','$passwd')";

2 - forego use of the assignment to variables, and plug the POST variables
directly into the sql statement instead.

in either event, i would recommend printing out the statement to the screen
so that you can be sure that the sql syntax is correct, and comment out the
insert command. when you're sure the syntax is correct, remove the print
statement and uncomment the insert command.

hope this helps

green


-----Original Message-----
From: Ken Larkman [mailto:admin@adept-hosting.net]
Sent: Wednesday, May 07, 2003 12:31 AM
To: Php-DB (E-mail)
Subject: [PHP-DB] Newbie help


Hello,

I am new to working with PHP and MySQL so I'm sure my mistake(s) are simple
enough. Basically, I'm trying to write a script(s) to add a row to a MySQL
database. I took the scripts below off a website and have been trying to
tweak them to do what i want. Unfortunately, the script usually gives me an
error message (the one defined in the script) and very occassionally inserts
a blank row in the database.

Any clues or advice on what I am doing wrong would be greatly appreciated.
Unfortunately, I have not found the solution on the web or MySQL site
(probably because I have no idea what I'm doing).

Thanks!

- Ken

RE: Newbie help

edward, what you are saying is indeed true. it is easier to just turn the
register_globals on, but php recommends against doing this for security
reasons.

green

-----Original Message-----
From: Becoming Digital [mailto:info@becomingdigital.com]
Sent: Wednesday, May 07, 2003 8:36 PM
To: _agreen@bellsouth.net; admin@adept-hosting.net; Php-DB (E-mail)
Subject: Re: [PHP-DB] Newbie help


> 2 - forego use of the assignment to variables, and plug the POST variables
> directly into the sql statement instead.

This is even easier if register_globals = On. Such a setup just eliminates
the
middle man.

Edward Dudlik
Becoming Digital
www.becomingdigital.com


----- Original Message -----
From: "Andy Green" <_agreen@bellsouth.net>
To: ; "Php-DB (E-mail)"
Sent: Wednesday, 07 May, 2003 00:43
Subject: RE: [PHP-DB] Newbie help


ken, it looks like there's a problem with this section of code

[CODE]
//Assign contents of form to variables
#$userid = $_POST['userid'];
#$passwd = $_POST['passwd'];

$sql = "INSERT INTO users (userid, passwd) VALUES (userid = 'userid',
passwd = 'passwd')";

[/CODE]

i'd recommend one of two things:

1 - uncomment out the assignment of the POST variables, and change your sql
statement to this:
$sql = "INSERT INTO users(userid,passwd) VALUES ('$userid','$passwd')";

2 - forego use of the assignment to variables, and plug the POST variables
directly into the sql statement instead.

in either event, i would recommend printing out the statement to the screen
so that you can be sure that the sql syntax is correct, and comment out the
insert command. when you're sure the syntax is correct, remove the print
statement and uncomment the insert command.

hope this helps

green


-----Original Message-----
From: Ken Larkman [mailto:admin@adept-hosting.net]
Sent: Wednesday, May 07, 2003 12:31 AM
To: Php-DB (E-mail)
Subject: [PHP-DB] Newbie help


Hello,

I am new to working with PHP and MySQL so I'm sure my mistake(s) are simple
enough. Basically, I'm trying to write a script(s) to add a row to a MySQL
database. I took the scripts below off a website and have been trying to
tweak them to do what i want. Unfortunately, the script usually gives me an
error message (the one defined in the script) and very occassionally inserts
a blank row in the database.

Any clues or advice on what I am doing wrong would be greatly appreciated.
Unfortunately, I have not found the solution on the web or MySQL site
(probably because I have no idea what I'm doing).

Thanks!

- Ken

Re: Newbie help

The recommendation (which was only made as of v.4.2.0) is there to prevent poor
coding resulting in insecure applications. As PHP is a loosely-typed language,
this can be a great concern, especially to new or inexperienced programmers.
Personally, I feel it better to code with register_globals = On as it forces me
to be that much more careful with my work.

Edward Dudlik
Becoming Digital
www.becomingdigital.com


----- Original Message -----
From: "Andy Green" <_agreen@bellsouth.net>
To: "Becoming Digital" ; ;
"Php-DB (E-mail)"
Sent: Wednesday, 07 May, 2003 20:51
Subject: RE: [PHP-DB] Newbie help


edward, what you are saying is indeed true. it is easier to just turn the
register_globals on, but php recommends against doing this for security
reasons.

green

-----Original Message-----
From: Becoming Digital [mailto:info@becomingdigital.com]
Sent: Wednesday, May 07, 2003 8:36 PM
To: _agreen@bellsouth.net; admin@adept-hosting.net; Php-DB (E-mail)
Subject: Re: [PHP-DB] Newbie help


> 2 - forego use of the assignment to variables, and plug the POST variables
> directly into the sql statement instead.

This is even easier if register_globals = On. Such a setup just eliminates
the
middle man.

Edward Dudlik
Becoming Digital
www.becomingdigital.com


----- Original Message -----
From: "Andy Green" <_agreen@bellsouth.net>
To: ; "Php-DB (E-mail)"
Sent: Wednesday, 07 May, 2003 00:43
Subject: RE: [PHP-DB] Newbie help


ken, it looks like there's a problem with this section of code

[CODE]
//Assign contents of form to variables
#$userid = $_POST['userid'];
#$passwd = $_POST['passwd'];

$sql = "INSERT INTO users (userid, passwd) VALUES (userid = 'userid',
passwd = 'passwd')";

[/CODE]

i'd recommend one of two things:

1 - uncomment out the assignment of the POST variables, and change your sql
statement to this:
$sql = "INSERT INTO users(userid,passwd) VALUES ('$userid','$passwd')";

2 - forego use of the assignment to variables, and plug the POST variables
directly into the sql statement instead.

in either event, i would recommend printing out the statement to the screen
so that you can be sure that the sql syntax is correct, and comment out the
insert command. when you're sure the syntax is correct, remove the print
statement and uncomment the insert command.

hope this helps

green


-----Original Message-----
From: Ken Larkman [mailto:admin@adept-hosting.net]
Sent: Wednesday, May 07, 2003 12:31 AM
To: Php-DB (E-mail)
Subject: [PHP-DB] Newbie help


Hello,

I am new to working with PHP and MySQL so I'm sure my mistake(s) are simple
enough. Basically, I'm trying to write a script(s) to add a row to a MySQL
database. I took the scripts below off a website and have been trying to
tweak them to do what i want. Unfortunately, the script usually gives me an
error message (the one defined in the script) and very occassionally inserts
a blank row in the database.

Any clues or advice on what I am doing wrong would be greatly appreciated.
Unfortunately, I have not found the solution on the web or MySQL site
(probably because I have no idea what I'm doing).

Thanks!

- Ken

Re: newbie help

You could do separate databases if you want. It all depends on how you want
to organize your data (keeping in mind data backup strategies and stuff).

Using separate databases on the same server, you might have another database
for the 'common' data. Any variables you store in the database that don't
really change and are common to all databases. Or if you log anything and
want to keep the log data in one central location, you could put it in the
'common' database.


If you wanted to store all the data in one database, you could use something
like forum threading techniques to show a parent/child relationship for the
customers.


id name parent
1 customerA NULL
2 cust1 1
3 cust2 1
4 custB 2
5 custC 2
6 custD 3


Then it's just a matter of drilling down, collecting a list of ID's for that
customer and the sub-customers.

Lotsof ways to tackle this problem.

-TG



----- Original Message -----
From: nhadie
To: php-db@lists.php.net
Date: Fri, 28 Sep 2007 11:30:42 +0800
Subject: [PHP-DB] newbie help

> Hi All,
>
> I would like to setup a system something like this
>
>
> customer A
>
> / \
>
>
> cust 1 cust 2
>
>
> / \ \
>
> cust B cust C cust D
>
> customer A has customer 1 and 2, cust 1 has cust B and C etc, etc.
> what i'm after is when a customer user logs in he can only see record
> of its customer, e.g cust A logs in, it can only see records of cust 1 and
> cust 2,
> if cust 2 is login it can only see cust D and so on
>
> how would i approach this? should every customer have it's own database,
> consisting of all tables i need e.g customer detail table,
> and i will use the database name as session variable, so that when they
> add records it be inserted on table under that database?
>
> sorry if my questions are confusing, hope anyone can help me, i just
> need help on how to approach it at the beginning so it will not be messy
> later on. Thank you.
>
> Regards,
> Nhadie
>
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: newbie help

Thanks for your reply, which solution would be faster and not put too
much load on the resources of the server? single or multiple database?
If i use a single database, would i be having same tables for each
customer, e.g. if i have customerinfo table for customers of A,
would i also have customerinfo table on customer 1 and 2 and so on, but
changing the name by prefixing something to the table name e.g
cust1_customerinfo.
i'm thinking if i use only a single table for, then i might have
problems on the file size limit of the OS, would i have that problem?

thanks again for your help, i really,really appreciate it.

regards,
nhadie




TG wrote:
> You could do separate databases if you want. It all depends on how you want
> to organize your data (keeping in mind data backup strategies and stuff).
>
> Using separate databases on the same server, you might have another database
> for the 'common' data. Any variables you store in the database that don't
> really change and are common to all databases. Or if you log anything and
> want to keep the log data in one central location, you could put it in the
> 'common' database.
>
>
> If you wanted to store all the data in one database, you could use something
> like forum threading techniques to show a parent/child relationship for the
> customers.
>
>
> id name parent
> 1 customerA NULL
> 2 cust1 1
> 3 cust2 1
> 4 custB 2
> 5 custC 2
> 6 custD 3
>
>
> Then it's just a matter of drilling down, collecting a list of ID's for that
> customer and the sub-customers.
>
> Lotsof ways to tackle this problem.
>
> -TG
>
>
>
> ----- Original Message -----
> From: nhadie
> To: php-db@lists.php.net
> Date: Fri, 28 Sep 2007 11:30:42 +0800
> Subject: [PHP-DB] newbie help
>
>
>> Hi All,
>>
>> I would like to setup a system something like this
>>
>>
>> customer A
>>
>> / \
>>
>>
>> cust 1 cust 2
>>
>>
>> / \ \
>>
>> cust B cust C cust D
>>
>> customer A has customer 1 and 2, cust 1 has cust B and C etc, etc.
>> what i'm after is when a customer user logs in he can only see record
>> of its customer, e.g cust A logs in, it can only see records of cust 1 and
>> cust 2,
>> if cust 2 is login it can only see cust D and so on
>>
>> how would i approach this? should every customer have it's own database,
>> consisting of all tables i need e.g customer detail table,
>> and i will use the database name as session variable, so that when they
>> add records it be inserted on table under that database?
>>
>> sorry if my questions are confusing, hope anyone can help me, i just
>> need help on how to approach it at the beginning so it will not be messy
>> later on. Thank you.
>>
>> Regards,
>> Nhadie
>>
>> --
>> PHP Database Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>>
>
>

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: newbie help

How resource intensive it is depends a lot on how much data you have and what
you're doing with it. You want to reduce the number of connections and
disconnects, since those are really intensive, but if everything is on the
same server, you can do cross database queries.

As for the table size exceeding the OS limit, that'd take quite a bit of data
to do. With proper database design, that shouldn't be too much of an
issue. If you have 2+gb of data in a single table, that's one monster
table.

Some info here about table size restrictions for MySQL:
http://dev.mysql.com/doc/refman/4.1/en/full-table.html

You could create a table and stuff it full of thousands of records and try to
check the physical file size of that table's file and see how tricky it
would be to actually 'fill' a table.


Ideally, for your 'customer' table would contain just the data that was
unique to that customer. Typically data that all your customers are going
to have a single entry for so you don't have a lot of empty spots.
Anything that you have multiple entries for or are unique to a single
customer, you could put in another table as meta data (additional
information that didn't fit in the main table).

You probably want to ignore my original parent/child threading idea. I was
just illustrating a way that you COULD do it.

What you may want to do is have a 'customers' table, which contain your
customers, then another table for the base information for your customer's
customers with an ID field that matches the entry in your 'customers' table.

For additional tables in the database, you could do something like you
meantioned... have "custname1_tablename1" and use a code in your
"customers" table to indicate the table prefix.

This kind of thing is used a lot in systems like phpBB, Gallery, etc so you
can have multiple copies installed on the same server. It'd be the same
idea when dealing with multiple customers.

Just make sure that the prefix you use for a customer doesn't use characters
that are bad for table names.

What kind of data are you thinking about storing for your customers and your
customer's customers? And what other data do you need to store for
whatever your webapp does?

-TG


----- Original Message -----
From: nhadie
To: php-db@lists.php.net
Date: Fri, 28 Sep 2007 23:49:23 +0800
Subject: Re: [PHP-DB] newbie help

> Thanks for your reply, which solution would be faster and not put too
> much load on the resources of the server? single or multiple database?
> If i use a single database, would i be having same tables for each
> customer, e.g. if i have customerinfo table for customers of A,
> would i also have customerinfo table on customer 1 and 2 and so on, but
> changing the name by prefixing something to the table name e.g
> cust1_customerinfo.
> i'm thinking if i use only a single table for, then i might have
> problems on the file size limit of the OS, would i have that problem?
>
> thanks again for your help, i really,really appreciate it.
>
> regards,
> nhadie
>
>
>
>
> TG wrote:
> > You could do separate databases if you want. It all depends on how you
> want
> > to organize your data (keeping in mind data backup strategies and stuff).
> >
> > Using separate databases on the same server, you might have another
> database
> > for the 'common' data. Any variables you store in the database that
> don't
> > really change and are common to all databases. Or if you log anything
> and
> > want to keep the log data in one central location, you could put it in
> the
> > 'common' database.
> >
> >
> > If you wanted to store all the data in one database, you could use
> something
> > like forum threading techniques to show a parent/child relationship for
> the
> > customers.
> >
> >
> > id name parent
> > 1 customerA NULL
> > 2 cust1 1
> > 3 cust2 1
> > 4 custB 2
> > 5 custC 2
> > 6 custD 3
> >
> >
> > Then it's just a matter of drilling down, collecting a list of ID's for
> that
> > customer and the sub-customers.
> >
> > Lotsof ways to tackle this problem.
> >
> > -TG
> >
> >
> >
> > ----- Original Message -----
> > From: nhadie
> > To: php-db@lists.php.net
> > Date: Fri, 28 Sep 2007 11:30:42 +0800
> > Subject: [PHP-DB] newbie help
> >
> >
> >> Hi All,
> >>
> >> I would like to setup a system something like this
> >>
> >>
> >> customer A
> >>
> >> / \
> >>
>
> >>
> >> cust 1 cust 2
> >>
>
> >>
> >> / \ \
> >>
> >> cust B cust C cust D
> >>
> >> customer A has customer 1 and 2, cust 1 has cust B and C etc, etc.
> >> what i'm after is when a customer user logs in he can only see record
> >> of its customer, e.g cust A logs in, it can only see records of cust 1
> and
> >> cust 2,
> >> if cust 2 is login it can only see cust D and so on
> >>
> >> how would i approach this? should every customer have it's own database,
> >> consisting of all tables i need e.g customer detail table,
> >> and i will use the database name as session variable, so that when they
> >> add records it be inserted on table under that database?
> >>
> >> sorry if my questions are confusing, hope anyone can help me, i just
> >> need help on how to approach it at the beginning so it will not be messy
> >> later on. Thank you.
> >>
> >> Regards,
> >> Nhadie
> >>
> >> --
> >> PHP Database Mailing List (http://www.php.net/)
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
> >>
> >
> >
>
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: newbie help

------=_Part_3958_19919776.1191047021941
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

This is definitely not the best advice in the world. The truth is you could
staple your eye lids open and never blink, but it wouldn't be very
beneficial. I highly suggest you invest some of your time in reading about
databases and how relational databases work, and more than that how they
work well, instead of trying to create some monster that will end up causing
you more stress than income.

I would also suggest you sit down and try to plan out whatever the hell you
are trying to do before you get too crazy. If you code like you describe
things here you are bound to confuse variable names and thats just crazy.
Try to clean up your idea and ill gladly direct you to some of your options.


and most of all, dont try to do this as TG has described here.

On 9/28/07, TG wrote:
>
>
> How resource intensive it is depends a lot on how much data you have and
> what
> you're doing with it. You want to reduce the number of connections and
> disconnects, since those are really intensive, but if everything is on the
> same server, you can do cross database queries.
>
> As for the table size exceeding the OS limit, that'd take quite a bit of
> data
> to do. With proper database design, that shouldn't be too much of an
> issue. If you have 2+gb of data in a single table, that's one monster
> table.
>
> Some info here about table size restrictions for MySQL:
> http://dev.mysql.com/doc/refman/4.1/en/full-table.html
>
> You could create a table and stuff it full of thousands of records and try
> to
> check the physical file size of that table's file and see how tricky it
> would be to actually 'fill' a table.
>
>
> Ideally, for your 'customer' table would contain just the data that was
> unique to that customer. Typically data that all your customers are going
> to have a single entry for so you don't have a lot of empty spots.
> Anything that you have multiple entries for or are unique to a single
> customer, you could put in another table as meta data (additional
> information that didn't fit in the main table).
>
> You probably want to ignore my original parent/child threading idea. I
> was
> just illustrating a way that you COULD do it.
>
> What you may want to do is have a 'customers' table, which contain your
> customers, then another table for the base information for your customer's
> customers with an ID field that matches the entry in your 'customers'
> table.
>
> For additional tables in the database, you could do something like you
> meantioned... have "custname1_tablename1" and use a code in your
> "customers" table to indicate the table prefix.
>
> This kind of thing is used a lot in systems like phpBB, Gallery, etc so
> you
> can have multiple copies installed on the same server. It'd be the same
> idea when dealing with multiple customers.
>
> Just make sure that the prefix you use for a customer doesn't use
> characters
> that are bad for table names.
>
> What kind of data are you thinking about storing for your customers and
> your
> customer's customers? And what other data do you need to store for
> whatever your webapp does?
>
> -TG
>
>
> ----- Original Message -----
> From: nhadie
> To: php-db@lists.php.net
> Date: Fri, 28 Sep 2007 23:49:23 +0800
> Subject: Re: [PHP-DB] newbie help
>
> > Thanks for your reply, which solution would be faster and not put too
> > much load on the resources of the server? single or multiple database?
> > If i use a single database, would i be having same tables for each
> > customer, e.g. if i have customerinfo table for customers of A,
> > would i also have customerinfo table on customer 1 and 2 and so on, but
> > changing the name by prefixing something to the table name e.g
> > cust1_customerinfo.
> > i'm thinking if i use only a single table for, then i might have
> > problems on the file size limit of the OS, would i have that problem?
> >
> > thanks again for your help, i really,really appreciate it.
> >
> > regards,
> > nhadie
> >
> >
> >
> >
> > TG wrote:
> > > You could do separate databases if you want. It all depends on how
> you
> > want
> > > to organize your data (keeping in mind data backup strategies and
> stuff).
> > >
> > > Using separate databases on the same server, you might have another
> > database
> > > for the 'common' data. Any variables you store in the database that
> > don't
> > > really change and are common to all databases. Or if you log anything
> > and
> > > want to keep the log data in one central location, you could put it in
> > the
> > > 'common' database.
> > >
> > >
> > > If you wanted to store all the data in one database, you could use
> > something
> > > like forum threading techniques to show a parent/child relationship
> for
> > the
> > > customers.
> > >
> > >
> > > id name parent
> > > 1 customerA NULL
> > > 2 cust1 1
> > > 3 cust2 1
> > > 4 custB 2
> > > 5 custC 2
> > > 6 custD 3
> > >
> > >
> > > Then it's just a matter of drilling down, collecting a list of ID's
> for
> > that
> > > customer and the sub-customers.
> > >
> > > Lotsof ways to tackle this problem.
> > >
> > > -TG
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: nhadie
> > > To: php-db@lists.php.net
> > > Date: Fri, 28 Sep 2007 11:30:42 +0800
> > > Subject: [PHP-DB] newbie help
> > >
> > >
> > >> Hi All,
> > >>
> > >> I would like to setup a system something like this
> > >>
> > >>
> > >> customer A
> > >>
> > >> / \
> > >>
> >
> > >>
> > >> cust 1 cust 2
> > >>
> >
> > >>
> > >> / \ \
> > >>
> > >> cust B cust C cust D
> > >>
> > >> customer A has customer 1 and 2, cust 1 has cust B and C etc, etc.
> > >> what i'm after is when a customer user logs in he can only see
> record
> > >> of its customer, e.g cust A logs in, it can only see records of cust
> 1
> > and
> > >> cust 2,
> > >> if cust 2 is login it can only see cust D and so on
> > >>
> > >> how would i approach this? should every customer have it's own
> database,
> > >> consisting of all tables i need e.g customer detail table,
> > >> and i will use the database name as session variable, so that when
> they
> > >> add records it be inserted on table under that database?
> > >>
> > >> sorry if my questions are confusing, hope anyone can help me, i just
> > >> need help on how to approach it at the beginning so it will not be
> messy
> > >> later on. Thank you.
> > >>
> > >> Regards,
> > >> Nhadie
> > >>
> > >> --
> > >> PHP Database Mailing List (http://www.php.net/)
> > >> To unsubscribe, visit: http://www.php.net/unsub.php
> > >>
> > >>
> > >>
> > >
> > >
> >
> > --
> > PHP Database Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

------=_Part_3958_19919776.1191047021941--

Re: newbie help

Nice blanket statements, Bob. What, exactly, is wrong with what I'm
describing?

What I've tried to do, without having more information about the type of data
and how he intends to use it, is give a high level idea of things that
could be tried. There's no way I can give an exact breakdown of exactly
how to configure anything without more information. All I did was outline
some general schemes that COULD be used on a high level.

Not trying to start a fight, but your message is borderline trolling (and of
course I'm responding... falling for it.. but I assume it wasn't meant as a
troll post).

It's not the BEST advice I could give because I don't have all the
information. Not saying I'm the smartest person on this list, but when
someone is looking for ideas, some ideas to try.. so you can grow and learn
at the very least.. are better than none. If a better idea comes along,
all the better. Hopefully the better solution will get posted to the list.

I'm not sure anything I said is as backwards as you make it out to be. So
let's keep it constructive. If you can point out clearly what I said
that's terribly wrong and give a better solution, please enlighten. Always
willing to learn new things if they are, indeed, better.

-TG

----- Original Message -----
From: "Bob Chatman"
To: TG
Cc: nhadie , php-db@lists.php.net
Date: Fri, 28 Sep 2007 23:23:41 -0700
Subject: Re: [PHP-DB] newbie help

> This is definitely not the best advice in the world. The truth is you could
> staple your eye lids open and never blink, but it wouldn't be very
> beneficial. I highly suggest you invest some of your time in reading about
> databases and how relational databases work, and more than that how they
> work well, instead of trying to create some monster that will end up causing
> you more stress than income.
>
> I would also suggest you sit down and try to plan out whatever the hell you
> are trying to do before you get too crazy. If you code like you describe
> things here you are bound to confuse variable names and thats just crazy.
> Try to clean up your idea and ill gladly direct you to some of your options.
> and most of all, dont try to do this as TG has described here.
>
> On 9/28/07, TG wrote:
> >
> >
> > How resource intensive it is depends a lot on how much data you have and
> > what
> > you're doing with it. You want to reduce the number of connections and
> > disconnects, since those are really intensive, but if everything is on the
> > same server, you can do cross database queries.
> >
> > As for the table size exceeding the OS limit, that'd take quite a bit of
> > data
> > to do. With proper database design, that shouldn't be too much of an
> > issue. If you have 2+gb of data in a single table, that's one monster
> > table.
> >
> > Some info here about table size restrictions for MySQL:
> > http://dev.mysql.com/doc/refman/4.1/en/full-table.html
> >
> > You could create a table and stuff it full of thousands of records and try
> > to
> > check the physical file size of that table's file and see how tricky it
> > would be to actually 'fill' a table.
> >
> >
> > Ideally, for your 'customer' table would contain just the data that was
> > unique to that customer. Typically data that all your customers are going
> > to have a single entry for so you don't have a lot of empty spots.
> > Anything that you have multiple entries for or are unique to a single
> > customer, you could put in another table as meta data (additional
> > information that didn't fit in the main table).
> >
> > You probably want to ignore my original parent/child threading idea. I
> > was
> > just illustrating a way that you COULD do it.
> >
> > What you may want to do is have a 'customers' table, which contain your
> > customers, then another table for the base information for your customer's
> > customers with an ID field that matches the entry in your 'customers'
> > table.
> >
> > For additional tables in the database, you could do something like you
> > meantioned... have "custname1_tablename1" and use a code in your
> > "customers" table to indicate the table prefix.
> >
> > This kind of thing is used a lot in systems like phpBB, Gallery, etc so
> > you
> > can have multiple copies installed on the same server. It'd be the same
> > idea when dealing with multiple customers.
> >
> > Just make sure that the prefix you use for a customer doesn't use
> > characters
> > that are bad for table names.
> >
> > What kind of data are you thinking about storing for your customers and
> > your
> > customer's customers? And what other data do you need to store for
> > whatever your webapp does?
> >
> > -TG
> >
> >
> > ----- Original Message -----
> > From: nhadie
> > To: php-db@lists.php.net
> > Date: Fri, 28 Sep 2007 23:49:23 +0800
> > Subject: Re: [PHP-DB] newbie help
> >
> > > Thanks for your reply, which solution would be faster and not put too
> > > much load on the resources of the server? single or multiple database?
> > > If i use a single database, would i be having same tables for each
> > > customer, e.g. if i have customerinfo table for customers of A,
> > > would i also have customerinfo table on customer 1 and 2 and so on, but
> > > changing the name by prefixing something to the table name e.g
> > > cust1_customerinfo.
> > > i'm thinking if i use only a single table for, then i might have
> > > problems on the file size limit of the OS, would i have that problem?
> > >
> > > thanks again for your help, i really,really appreciate it.
> > >
> > > regards,
> > > nhadie
> > >
> > >
> > >
> > >
> > > TG wrote:
> > > > You could do separate databases if you want. It all depends on how
> > you
> > > want
> > > > to organize your data (keeping in mind data backup strategies and
> > stuff).
> > > >
> > > > Using separate databases on the same server, you might have another
> > > database
> > > > for the 'common' data. Any variables you store in the database that
> > > don't
> > > > really change and are common to all databases. Or if you log anything
> > > and
> > > > want to keep the log data in one central location, you could put it in
> > > the
> > > > 'common' database.
> > > >
> > > >
> > > > If you wanted to store all the data in one database, you could use
> > > something
> > > > like forum threading techniques to show a parent/child relationship
> > for
> > > the
> > > > customers.
> > > >
> > > >
> > > > id name parent
> > > > 1 customerA NULL
> > > > 2 cust1 1
> > > > 3 cust2 1
> > > > 4 custB 2
> > > > 5 custC 2
> > > > 6 custD 3
> > > >
> > > >
> > > > Then it's just a matter of drilling down, collecting a list of ID's
> > for
> > > that
> > > > customer and the sub-customers.
> > > >
> > > > Lotsof ways to tackle this problem.
> > > >
> > > > -TG
> > > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: nhadie
> > > > To: php-db@lists.php.net
> > > > Date: Fri, 28 Sep 2007 11:30:42 +0800
> > > > Subject: [PHP-DB] newbie help
> > > >
> > > >
> > > >> Hi All,
> > > >>
> > > >> I would like to setup a system something like this
> > > >>
> > > >>
> > > >> customer A
> > > >>
> > > >> / \
> > > >>
> > >
> > > >>
> > > >> cust 1 cust 2
> > > >>
> > >
> > > >>
> > > >> / \ \
> > > >>
> > > >> cust B cust C cust D
> > > >>
> > > >> customer A has customer 1 and 2, cust 1 has cust B and C etc, etc.
> > > >> what i'm after is when a customer user logs in he can only see
> > record
> > > >> of its customer, e.g cust A logs in, it can only see records of cust
> > 1
> > > and
> > > >> cust 2,
> > > >> if cust 2 is login it can only see cust D and so on
> > > >>
> > > >> how would i approach this? should every customer have it's own
> > database,
> > > >> consisting of all tables i need e.g customer detail table,
> > > >> and i will use the database name as session variable, so that when
> > they
> > > >> add records it be inserted on table under that database?
> > > >>
> > > >> sorry if my questions are confusing, hope anyone can help me, i just
> > > >> need help on how to approach it at the beginning so it will not be
> > messy
> > > >> later on. Thank you.
> > > >>
> > > >> Regards,
> > > >> Nhadie

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: newbie help

I'd like to apologize to both of you, this is my fault as i did not
really clear what my requirements are .

basically it will be for my VoIP system, Customer A (which is me) will
have customers that may also be a reseller, so this is where Cust 1 will
have Cust B.
Each customer will have a login name, that they can use to check cdr's,
view their rates, create rates for their customers (if customer is a
reseller, so that they
can top-up whatever rate was assigned to it by its parent) billing
(sending invoice via e-mail) and trouble ticket. that's what is in the
plan for now.

Thank you

Regards,
Nhadie


TG wrote:
> Nice blanket statements, Bob. What, exactly, is wrong with what I'm
> describing?
>
> What I've tried to do, without having more information about the type of data
> and how he intends to use it, is give a high level idea of things that
> could be tried. There's no way I can give an exact breakdown of exactly
> how to configure anything without more information. All I did was outline
> some general schemes that COULD be used on a high level.
>
> Not trying to start a fight, but your message is borderline trolling (and of
> course I'm responding... falling for it.. but I assume it wasn't meant as a
> troll post).
>
> It's not the BEST advice I could give because I don't have all the
> information. Not saying I'm the smartest person on this list, but when
> someone is looking for ideas, some ideas to try.. so you can grow and learn
> at the very least.. are better than none. If a better idea comes along,
> all the better. Hopefully the better solution will get posted to the list.
>
> I'm not sure anything I said is as backwards as you make it out to be. So
> let's keep it constructive. If you can point out clearly what I said
> that's terribly wrong and give a better solution, please enlighten. Always
> willing to learn new things if they are, indeed, better.
>
> -TG
>
> ----- Original Message -----
> From: "Bob Chatman"
> To: TG
> Cc: nhadie , php-db@lists.php.net
> Date: Fri, 28 Sep 2007 23:23:41 -0700
> Subject: Re: [PHP-DB] newbie help
>
>
>> This is definitely not the best advice in the world. The truth is you could
>> staple your eye lids open and never blink, but it wouldn't be very
>> beneficial. I highly suggest you invest some of your time in reading about
>> databases and how relational databases work, and more than that how they
>> work well, instead of trying to create some monster that will end up causing
>> you more stress than income.
>>
>> I would also suggest you sit down and try to plan out whatever the hell you
>> are trying to do before you get too crazy. If you code like you describe
>> things here you are bound to confuse variable names and thats just crazy.
>> Try to clean up your idea and ill gladly direct you to some of your options.
>> and most of all, dont try to do this as TG has described here.
>>
>> On 9/28/07, TG wrote:
>>
>>> How resource intensive it is depends a lot on how much data you have and
>>> what
>>> you're doing with it. You want to reduce the number of connections and
>>> disconnects, since those are really intensive, but if everything is on the
>>> same server, you can do cross database queries.
>>>
>>> As for the table size exceeding the OS limit, that'd take quite a bit of
>>> data
>>> to do. With proper database design, that shouldn't be too much of an
>>> issue. If you have 2+gb of data in a single table, that's one monster
>>> table.
>>>
>>> Some info here about table size restrictions for MySQL:
>>> http://dev.mysql.com/doc/refman/4.1/en/full-table.html
>>>
>>> You could create a table and stuff it full of thousands of records and try
>>> to
>>> check the physical file size of that table's file and see how tricky it
>>> would be to actually 'fill' a table.
>>>
>>>
>>> Ideally, for your 'customer' table would contain just the data that was
>>> unique to that customer. Typically data that all your customers are going
>>> to have a single entry for so you don't have a lot of empty spots.
>>> Anything that you have multiple entries for or are unique to a single
>>> customer, you could put in another table as meta data (additional
>>> information that didn't fit in the main table).
>>>
>>> You probably want to ignore my original parent/child threading idea. I
>>> was
>>> just illustrating a way that you COULD do it.
>>>
>>> What you may want to do is have a 'customers' table, which contain your
>>> customers, then another table for the base information for your customer's
>>> customers with an ID field that matches the entry in your 'customers'
>>> table.
>>>
>>> For additional tables in the database, you could do something like you
>>> meantioned... have "custname1_tablename1" and use a code in your
>>> "customers" table to indicate the table prefix.
>>>
>>> This kind of thing is used a lot in systems like phpBB, Gallery, etc so
>>> you
>>> can have multiple copies installed on the same server. It'd be the same
>>> idea when dealing with multiple customers.
>>>
>>> Just make sure that the prefix you use for a customer doesn't use
>>> characters
>>> that are bad for table names.
>>>
>>> What kind of data are you thinking about storing for your customers and
>>> your
>>> customer's customers? And what other data do you need to store for
>>> whatever your webapp does?
>>>
>>> -TG
>>>
>>>
>>> ----- Original Message -----
>>> From: nhadie
>>> To: php-db@lists.php.net
>>> Date: Fri, 28 Sep 2007 23:49:23 +0800
>>> Subject: Re: [PHP-DB] newbie help
>>>
>>>
>>>> Thanks for your reply, which solution would be faster and not put too
>>>> much load on the resources of the server? single or multiple database?
>>>> If i use a single database, would i be having same tables for each
>>>> customer, e.g. if i have customerinfo table for customers of A,
>>>> would i also have customerinfo table on customer 1 and 2 and so on, but
>>>> changing the name by prefixing something to the table name e.g
>>>> cust1_customerinfo.
>>>> i'm thinking if i use only a single table for, then i might have
>>>> problems on the file size limit of the OS, would i have that problem?
>>>>
>>>> thanks again for your help, i really,really appreciate it.
>>>>
>>>> regards,
>>>> nhadie
>>>>
>>>>
>>>>
>>>>
>>>> TG wrote:
>>>>
>>>>> You could do separate databases if you want. It all depends on how
>>>>>
>>> you
>>>
>>>> want
>>>>
>>>>> to organize your data (keeping in mind data backup strategies and
>>>>>
>>> stuff).
>>>
>>>>> Using separate databases on the same server, you might have another
>>>>>
>>>> database
>>>>
>>>>> for the 'common' data. Any variables you store in the database that
>>>>>
>>>> don't
>>>>
>>>>> really change and are common to all databases. Or if you log anything
>>>>>
>>>> and
>>>>
>>>>> want to keep the log data in one central location, you could put it in
>>>>>
>>>> the
>>>>
>>>>> 'common' database.
>>>>>
>>>>>
>>>>> If you wanted to store all the data in one database, you could use
>>>>>
>>>> something
>>>>
>>>>> like forum threading techniques to show a parent/child relationship
>>>>>
>>> for
>>>
>>>> the
>>>>
>>>>> customers.
>>>>>
>>>>>
>>>>> id name parent
>>>>> 1 customerA NULL
>>>>> 2 cust1 1
>>>>> 3 cust2 1
>>>>> 4 custB 2
>>>>> 5 custC 2
>>>>> 6 custD 3
>>>>>
>>>>>
>>>>> Then it's just a matter of drilling down, collecting a list of ID's
>>>>>
>>> for
>>>
>>>> that
>>>>
>>>>> customer and the sub-customers.
>>>>>
>>>>> Lotsof ways to tackle this problem.
>>>>>
>>>>> -TG
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>> From: nhadie
>>>>> To: php-db@lists.php.net
>>>>> Date: Fri, 28 Sep 2007 11:30:42 +0800
>>>>> Subject: [PHP-DB] newbie help
>>>>>
>>>>>
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I would like to setup a system something like this
>>>>>>
>>>>>>
>>>>>> customer A
>>>>>>
>>>>>> / \
>>>>>>
>>>>>>
>>>>>> cust 1 cust 2
>>>>>>
>>>>>>
>>>>>> / \ \
>>>>>>
>>>>>> cust B cust C cust D
>>>>>>
>>>>>> customer A has customer 1 and 2, cust 1 has cust B and C etc, etc.
>>>>>> what i'm after is when a customer user logs in he can only see
>>>>>>
>>> record
>>>
>>>>>> of its customer, e.g cust A logs in, it can only see records of cust
>>>>>>
>>> 1
>>>
>>>> and
>>>>
>>>>>> cust 2,
>>>>>> if cust 2 is login it can only see cust D and so on
>>>>>>
>>>>>> how would i approach this? should every customer have it's own
>>>>>>
>>> database,
>>>
>>>>>> consisting of all tables i need e.g customer detail table,
>>>>>> and i will use the database name as session variable, so that when
>>>>>>
>>> they
>>>
>>>>>> add records it be inserted on table under that database?
>>>>>>
>>>>>> sorry if my questions are confusing, hope anyone can help me, i just
>>>>>> need help on how to approach it at the beginning so it will not be
>>>>>>
>>> messy
>>>
>>>>>> later on. Thank you.
>>>>>>
>>>>>> Regards,
>>>>>> Nhadie
>>>>>>
>
>

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php