Shaun Thomas wrote:
> On 03/15/2013 08:36 AM, Kevin Grittner wrote:
>
>> I occasionally hear someone maintaining that having a meaningless
>> sequential ID column as the primary key of each table is required
>> by the relational model.
>
> You know, I've heard you mention this a couple times, and
On 2013-03-15, lender wrote:
> Hello.
>
> We are currently redesigning a medium/large office management web
> application. There are 75 tables in our existing PostgreSQL database,
> but that number is artificially low, due to some unfortunate design choices.
>
> The main culprits are two tables na
On 03/15/2013 08:36 AM, Kevin Grittner wrote:
I occasionally hear someone maintaining that having a meaningless
sequential ID column as the primary key of each table is required
by the relational model.
You know, I've heard you mention this a couple times, and I still don't
understand why you
Thanks everybody for your comments.
On 2013-03-15 16:03, François Beausoleil wrote:
> Keeping a meaningless ID is not a problem in and of itself. It makes
> it easier to edit records from the UI, since you can reference the ID in
> the UPDATE and DELETE statements, without fear of colliding with
>
Le 2013-03-15 à 09:58, Thomas Kellerer a écrit :
> Kevin Grittner, 15.03.2013 14:36:
>>
>> I occasionally hear someone maintaining that having a meaningless
>> sequential ID column as the primary key of each table is required
>> by the relational model. At those moments I swear I can actually
>
Kevin Grittner, 15.03.2013 14:36:
I occasionally hear someone maintaining that having a meaningless
sequential ID column as the primary key of each table is required
by the relational model. At those moments I swear I can actually
hear E.F. Codd turning in his grave. It was a requirement of ol
lender wrote:
> So, my first main question would be: is it "normal" or desirable
> to have that many tiny tables?
Yes.
> And is it a problem that many of the tables have the same (or a
> similar) column definitions?
No.
> To summarize, the second question is whether we should ditch the
> arti
Hello.
We are currently redesigning a medium/large office management web
application. There are 75 tables in our existing PostgreSQL database,
but that number is artificially low, due to some unfortunate design choices.
The main culprits are two tables named "catalog" and "catalog_entries".
They
On Fri, Aug 21, 2009 at 12:50 AM,
stone...@excite.com wrote:
> Hey all,
>
> My company is designing a database in which we intend to store data for
> several customers. We are trying to decide if,
>
> A: we want to store all customer data in one set of tables with customer_id
> fields separating
"stone...@excite.com" wrote:
>
>
> >stone...@excite.com wrote:
> >> Hey all,
> >>
> >> My company is designing a database in which we intend to store data
> >> for several customers. We are trying to decide if,
> >>
> >> A: we want to store all customer data in one set of tables with
> >> custome
>stone...@excite.com wrote:
>> Hey all,
>>
>> My company is designing a database in which we intend to store data
>> for several customers. We are trying to decide if,
>>
>> A: we want to store all customer data in one set of tables with
>> customer_id fields separating the data or,
>> B: storing
stone...@excite.com wrote:
Hey all,
My company is designing a database in which we intend to store data
for several customers. We are trying to decide if,
A: we want to store all customer data in one set of tables with
customer_id fields separating the data or,
B: storing each customers
Hey all,My company is designing a database in which we intend to store data for
several customers. We are trying to decide if,A: we want to store all
customer data in one set of tables with customer_id fields separating the data
or,B: storing each customers data in a separate schema.I'd like
13 matches
Mail list logo
