On Sat, 12 Sep 2009, CED wrote:
> If that was the case, they wouldn't have known which files to "tar up".
I assumed they tar'ed up the web application and logs. Hardly a
rapier-like analysis...
--
Aj.
___
New York PHP User Group Community Talk Ma
Here's my input on this same topic from a couple weeks ago on this list:
http://lists.nyphp.org/pipermail/talk/2009-August/028910.html
I must have missed that. Sorry for the repost.
So you would recommend using tablename_ in the beginning of every field in
a table?
__
Hi Matt:
Here's my input on this same topic from a couple weeks ago on this list:
http://lists.nyphp.org/pipermail/talk/2009-August/028910.html
Good night,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
I think the definition would be in the services table.
The entity is a service, hosting or something. The columns in services
should define the entity (serivce).
So the service_id in account_services ties back to what the service is.
On Sep 12, 2009, at 10:27 PM, Matt Juszczak wrote:
accou
Right. Like I said, the underscore doesn't have any special semantic
meaning, unless the following two characters are an "i" and then a "d"
Makes sense :)
But it's just a thought. I've never done things that way, and it seems
confusing -- the visual difference between _ and __ is too small.
account_services
account_service_id
account_id
service_id
start_date
end_date
...
So you have a one to many customers to accounts relation. You have a one to
many accounts to account_services and a one to many services to
account_services.
Right
On Sep 12, 2009, at 9:45 PM, Matt Juszczak wrote:
For lookup tables like an "account type", I'd certainly call the
table "account_type", and not just "type". Eventually you'll have
an "order type" to deal with, so ... yeah.
In the larger picture, you want to maintain enough specificity to
Well a customer to account would be a one to many.
customers
customer_id
name
accounts
account_id
name
customer_id
...
services
service_id
name
...
account_services
account_service_id
account_i
Part of good db design is to plan way into the future. Your customers
may only have one account now, but is it possible in the future they could
have 2? These are HUGE decisions that can come back with really big teeth.
Well, this is all in an example. Even if a customer could have more than
Matt,
It is really hard to talk about tables without understanding the data
needs. If you want to come up with an example of what you need to do
we could all suggest structures. I don't really get the levels concept
of a relational db, but what do I know :)
Part of good db design is to
For lookup tables like an "account type", I'd certainly call the table
"account_type", and not just "type". Eventually you'll have an "order type"
to deal with, so ... yeah.
In the larger picture, you want to maintain enough specificity to keep things
from getting confusing. This is largely
Matt,
This is how I originally learned it way back when and still believe.
SQL should read almost like english.
Tables are named in the plural.
Columns are singular.
id columns are the table name singular "_id".
For example.
create table users (
user_id int auto_increment not null,
On Sep 12, 2009, at 9:09 PM, Matt Juszczak wrote:
I used to use the former method almost exclusively. However, as I
started playing with various frameworks, I've switched to the
latter as those I've worked with kind of expect it. Probably
because various _call() based magic ends up looki
I used to use the former method almost exclusively. However, as I started
playing with various frameworks, I've switched to the latter as those I've
worked with kind of expect it. Probably because various _call() based magic
ends up looking nicer in userland code.
If you have more specific c
In my experience, the most important thing is consistency. Almost
everything else is a matter of taste.
For instance, some folks like to name columns with the table name as a
prefix on every column (except foreign keys):
create table a(
a_id int,
a_value varchar(64),
Does anyone have any good naming conventions for mysql databases and tables and
columns? I'm developing a complex lamp project now, and my normal convention
doesn't seem to want to work too well for this project - there are a few
conflicts.
___
New
One thing I haven't seen is too much help with finding tools that make
problems like this scarce if not non-existant...
I've been using an application called Atomic Secured Linux - it just works
and the team behind it makes updates to the rules constantly
but it's not just mod-sec rules - it also
17 matches
Mail list logo
