php-general Digest 10 Jun 2013 14:15:25 -0000 Issue 8261
Topics (messages 321352 through 321359):
Re: Using Table prefixes
321352 by: Ashley Sheridan
321353 by: Tedd Sperling
321354 by: Julian Wanke
321355 by: Tamara Temple
321356 by: Tamara Temple
321357 by: Bastien
321358 by: Bastien
321359 by: Tedd Sperling
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
dealTek <deal...@gmail.com> wrote:
>Hi all,
>
>I can see the basic need for a table prefix in a case where you may use
>one mysql database for several projects at once so as to distinguish
>tables per project like...
>
>
>Project 1
>
>mysales_contacts
>mysales_invoices
>etc
>
>and
>
>jobs_contacts
>jobs_invoices
>
>however I was told a long time ago to use a prefix "tbl_" like
>tbl_Mytable but I don't really see much need for this by itself ... Am
>I missing something?
>
>
>
>--
>Thanks,
>Dave - DealTek
>deal...@gmail.com
>[db-3]
I think that's a pattern that people use to distinguish their tables from
views, etc, but personally I find it a little pointless. It doesn't really help
in any way, and just means more typing.
Using a prefix for a set of tables in one db where you might have several
things using the db (i.e. some hosting limits the databases you can have) makes
sense, and especially so if you name it sensibly as in your first example.
Thanks,
Ash
--- End Message ---
--- Begin Message ---
On Jun 8, 2013, at 3:00 PM, Ashley Sheridan <a...@ashleysheridan.co.uk> wrote:
dealTek <deal...@gmail.com> wrote:
>
>> I can see the basic need for a table prefix in a case where you may use
>> one mysql database for several projects at once so as to distinguish
>> tables per project like...
>>
>> -snip-
>> however I was told a long time ago to use a prefix "tbl_" like
>> tbl_Mytable but I don't really see much need for this by itself ... Am
>> I missing something?
>
> I think that's a pattern that people use to distinguish their tables from
> views, etc, but personally I find it a little pointless. It doesn't really
> help in any way, and just means more typing.
>
> Using a prefix for a set of tables in one db where you might have several
> things using the db (i.e. some hosting limits the databases you can have)
> makes sense, and especially so if you name it sensibly as in your first
> example.
> Thanks,
> Ash
I agree, but more than that I also set up databases specifically for clients
such that all the tables in them are related to the client and not each other,
such as:
client1_db
contacts
invoices
etc
and
client2_db
contacts
invoices
etc
As such, the "tbl_" prefix is not needed.
Cheers,
tedd
_____________________
tedd.sperl...@gmail.com
http://sperling.com
--- End Message ---
--- Begin Message ---
A database for each client? Isn't that over-powered? If you have 1000
clients, you would loose the overview over your databases...
Am 08.06.2013, 21:46 Uhr, schrieb Tedd Sperling <tedd.sperl...@gmail.com>:
On Jun 8, 2013, at 3:00 PM, Ashley Sheridan <a...@ashleysheridan.co.uk>
wrote:
dealTek <deal...@gmail.com> wrote:
I can see the basic need for a table prefix in a case where you may use
one mysql database for several projects at once so as to distinguish
tables per project like...
-snip-
however I was told a long time ago to use a prefix "tbl_" like
tbl_Mytable but I don't really see much need for this by itself ... Am
I missing something?
I think that's a pattern that people use to distinguish their tables
from views, etc, but personally I find it a little pointless. It
doesn't really help in any way, and just means more typing.
Using a prefix for a set of tables in one db where you might have
several things using the db (i.e. some hosting limits the databases you
can have) makes sense, and especially so if you name it sensibly as in
your first example.
Thanks,
Ash
I agree, but more than that I also set up databases specifically for
clients such that all the tables in them are related to the client and
not each other, such as:
client1_db
contacts
invoices
etc
and
client2_db
contacts
invoices
etc
As such, the "tbl_" prefix is not needed.
Cheers,
tedd
_____________________
tedd.sperl...@gmail.com
http://sperling.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
Tedd Sperling <tedd.sperl...@gmail.com> wrote:
> On Jun 8, 2013, at 3:00 PM, Ashley Sheridan <a...@ashleysheridan.co.uk> wrote:
> dealTek <deal...@gmail.com> wrote:
> >
> >> I can see the basic need for a table prefix in a case where you may use
> >> one mysql database for several projects at once so as to distinguish
> >> tables per project like...
> >>
> >> -snip-
> >> however I was told a long time ago to use a prefix "tbl_" like
> >> tbl_Mytable but I don't really see much need for this by itself ... Am
> >> I missing something?
> >
> > I think that's a pattern that people use to distinguish their tables from
> > views, etc, but personally I find it a little pointless. It doesn't really
> > help in any way, and just means more typing.
> >
> > Using a prefix for a set of tables in one db where you might have several
> > things using the db (i.e. some hosting limits the databases you can have)
> > makes sense, and especially so if you name it sensibly as in your first
> > example.
> > Thanks,
> > Ash
>
> I agree, but more than that I also set up databases specifically for clients
> such that all the tables in them are related to the client and not each
> other, such as:
>
> client1_db
>
> contacts
> invoices
> etc
>
> and
>
> client2_db
>
> contacts
> invoices
> etc
>
> As such, the "tbl_" prefix is not needed.
>
> Cheers,
>
> tedd
>
> _____________________
> tedd.sperl...@gmail.com
> http://sperling.com
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
In a multi-client situation like Tedd describes, it is rather more
important to segregate client's data, otherwise you need to do a fair
bit of permissions management to keep rogue employees/contractors at the
various clients from snooping around. (It happens!)
OTOH, when it's your own apps, and you are db restricted as Ash
mentions, the table prefix thing can be useful. Personally, I don't do
that, but that's because I am rarely resource-bound in that way. One db
per app, basically.
--- End Message ---
--- Begin Message ---
Julian Wanke <jswp...@gmx.at> wrote:
> A database for each client? Isn't that over-powered? If you have 1000
> clients, you would loose the overview over your databases...
I believe what is being talked about is one DB per application install --
'client' can be a way-overloaded term.
>
> Am 08.06.2013, 21:46 Uhr, schrieb Tedd Sperling <tedd.sperl...@gmail.com>:
>
> > On Jun 8, 2013, at 3:00 PM, Ashley Sheridan
> > <a...@ashleysheridan.co.uk> wrote:
> > dealTek <deal...@gmail.com> wrote:
> >>
> >>> I can see the basic need for a table prefix in a case where you may use
> >>> one mysql database for several projects at once so as to distinguish
> >>> tables per project like...
> >>>
> >>> -snip-
> >>> however I was told a long time ago to use a prefix "tbl_" like
> >>> tbl_Mytable but I don't really see much need for this by itself ... Am
> >>> I missing something?
> >>
> >> I think that's a pattern that people use to distinguish their
> >> tables from views, etc, but personally I find it a little
> >> pointless. It doesn't really help in any way, and just means more
> >> typing.
> >>
> >> Using a prefix for a set of tables in one db where you might have
> >> several things using the db (i.e. some hosting limits the databases
> >> you can have) makes sense, and especially so if you name it
> >> sensibly as in your first example.
> >> Thanks,
> >> Ash
> >
> > I agree, but more than that I also set up databases specifically for
> > clients such that all the tables in them are related to the client
> > and not each other, such as:
> >
> > client1_db
> >
> > contacts
> > invoices
> > etc
> >
> > and
> >
> > client2_db
> >
> > contacts
> > invoices
> > etc
> >
> > As such, the "tbl_" prefix is not needed.
> >
> > Cheers,
> >
> > tedd
> >
> > _____________________
> > tedd.sperl...@gmail.com
> > http://sperling.com
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--- End Message ---
--- Begin Message ---
Bastien Koert
On 2013-06-08, at 5:58 PM, Tamara Temple <tamouse.li...@gmail.com> wrote:
> Julian Wanke <jswp...@gmx.at> wrote:
>> A database for each client? Isn't that over-powered? If you have 1000
>> clients, you would loose the overview over your databases...
>
> I believe what is being talked about is one DB per application install --
> 'client' can be a way-overloaded term.
Some projects or apps require one db per client. But it does become a pain to
manage.
Bastien
--- End Message ---
--- Begin Message ---
Bastien Koert
On 2013-06-08, at 5:56 PM, Tamara Temple <tamouse.li...@gmail.com> wrote:
> Tedd Sperling <tedd.sperl...@gmail.com> wrote:
>> On Jun 8, 2013, at 3:00 PM, Ashley Sheridan <a...@ashleysheridan.co.uk>
>> wrote:
>> dealTek <deal...@gmail.com> wrote:
>>>
>>>> I can see the basic need for a table prefix in a case where you may use
>>>> one mysql database for several projects at once so as to distinguish
>>>> tables per project like...
>>>>
>>>> -snip-
>>>> however I was told a long time ago to use a prefix "tbl_" like
>>>> tbl_Mytable but I don't really see much need for this by itself ... Am
>>>> I missing something?
>>>
>>> I think that's a pattern that people use to distinguish their tables from
>>> views, etc, but personally I find it a little pointless. It doesn't really
>>> help in any way, and just means more typing.
>>>
>>> Using a prefix for a set of tables in one db where you might have several
>>> things using the db (i.e. some hosting limits the databases you can have)
>>> makes sense, and especially so if you name it sensibly as in your first
>>> example.
>>> Thanks,
>>> Ash
>>
>> I agree, but more than that I also set up databases specifically for clients
>> such that all the tables in them are related to the client and not each
>> other, such as:
>>
>> client1_db
>>
>> contacts
>> invoices
>> etc
>>
>> and
>>
>> client2_db
>>
>> contacts
>> invoices
>> etc
>>
>> As such, the "tbl_" prefix is not needed.
>>
>> Cheers,
>>
>> tedd
>>
>> _____________________
>> tedd.sperl...@gmail.com
>> http://sperling.com
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>
> In a multi-client situation like Tedd describes, it is rather more
> important to segregate client's data, otherwise you need to do a fair
> bit of permissions management to keep rogue employees/contractors at the
> various clients from snooping around. (It happens!)
>
> OTOH, when it's your own apps, and you are db restricted as Ash
> mentions, the table prefix thing can be useful. Personally, I don't do
> that, but that's because I am rarely resource-bound in that way. One db
> per app, basically.
>
I have run into situations where I prefix with the app name due to same table
names in the same db. This was on a large db2 install.
--- End Message ---
--- Begin Message ---
On Jun 8, 2013, at 4:17 PM, Julian Wanke <jswp...@gmx.at> wrote:
> A database for each client? Isn't that over-powered? If you have 1000
> clients, you would loose the overview over your databases...
What -- people have more than one client?!?
My thoughts:
A client is like a girlfriend -- if you have too many, things can get real
ugly, real fast.
If you have over 10 clients (let alone 1000), then you're probably overworked
and not doing your best for each.
My advise -- raise your rates until you narrow those clients down to a
manageable size. Both you and your clients will be happier.
At least, that's been my experience -- YMMV.
Cheers,
tedd
_____________________
tedd.sperl...@gmail.com
http://sperling.com
--- End Message ---
