On Aug 1, 2014, at 6:57 AM, Wolfgang Keller wrote:
>> Celko's books are great but surrogate integer PKs are an unavoidable
>> practice within relational databases, they are a requirement of most
>> DBAs I've dealt with
>
> Those guys don't even have a faint clue how clueless they are.
>
> In
On Wednesday, July 30, 2014 12:18:03 PM UTC-4, Michael Bayer wrote:
>
> Typically a UNIQUE constraint is placed on the “natural” key to prevent
> dupes.
>
Sidenote on this:
If the field isn't case-sensitive, then you are often better off using a
function on the constraint if the database all
> Celko's books are great but surrogate integer PKs are an unavoidable
> practice within relational databases, they are a requirement of most
> DBAs I've dealt with
Those guys don't even have a faint clue how clueless they are.
In fact this very issue is *THE* "litmus test" question I ask people
On Wed, 30 Jul 2014, Michael Bayer wrote:
You make a single explicit UniqueConstraint object that specifies all three.
Thanks, Mike. I missed that in the docs.
Next question will appear only after a thorough search of your book.
Rich
--
You received this message because you are subscrib
You make a single explicit UniqueConstraint object that specifies all three.
Sent from my iPhone
> On Jul 30, 2014, at 2:30 PM, Rich Shepard wrote:
>
>> On Wed, 30 Jul 2014, Michael Bayer wrote:
>>
>> Typically a UNIQUE constraint is placed on the "natural" key to prevent
>> dupes.
>
> I can
On Wed, 30 Jul 2014, Michael Bayer wrote:
Typically a UNIQUE constraint is placed on the "natural" key to prevent
dupes.
I can see this when the natural key is a single column, but wonder how a
compound natural key is represented if a serial integer is used as the
surrogate 'id' key. For exa
On Wed, 30 Jul 2014, Michael Bayer wrote:
With that, plus the predictable indexing, I'm always going to use them.
But, I think there's a fair degree of preference still here. With natural
PKs, the biggest issue is how much space indexes are going to take up
considering that everything that FKs t
On Jul 30, 2014, at 12:28 PM, Rich Shepard wrote:
> On Wed, 30 Jul 2014, Michael Bayer wrote:
>
>> Celko's books are great but surrogate integer PKs are an unavoidable
>> practice within relational databases, they are a requirement of most DBAs
>> I've dealt with as they perform predictably in
On Wed, 30 Jul 2014, Michael Bayer wrote:
Celko's books are great but surrogate integer PKs are an unavoidable
practice within relational databases, they are a requirement of most DBAs
I've dealt with as they perform predictably in terms of indexing and space
requirements, especially considering
On Jul 30, 2014, at 9:04 AM, Rich Shepard wrote:
> On Wed, 30 Jul 2014, Werner wrote:
>
>> I don't like using 'name' columns as primary keys I would instead use an
>> 'id' column and would set 'index=True' on the name column.
>
> Werner,
>
> The use of natural keys (such as a vehicle VIN, th
On Wed, 30 Jul 2014, Werner wrote:
His book looks very interesting.
Werner,
And quite useful.
I can see the advantage these things, but not sure on 'agency_contacts'.
I agree. But, it is unlikely that there would be two staffers with the
same last name in the same district office of a
Hi Rich,
On 7/30/2014 15:04, Rich Shepard wrote:
On Wed, 30 Jul 2014, Werner wrote:
I don't like using 'name' columns as primary keys I would instead use an
'id' column and would set 'index=True' on the name column.
Werner,
The use of natural keys (such as a vehicle VIN, the US's SSN, or
On Wed, 30 Jul 2014, Werner wrote:
I don't like using 'name' columns as primary keys I would instead use an
'id' column and would set 'index=True' on the name column.
Werner,
The use of natural keys (such as a vehicle VIN, the US's SSN, or equipment
serial number) is prefered over an artifi
Hi Rich,
I don't like using 'name' columns as primary keys I would instead use an
'id' column and would set 'index=True' on the name column.
On the primary key also define a Sequence:
Column('id', Integer, Sequence('tablename_id_seq'), primary_key=True)
http://sqlalchemy.readthedocs.org/en/r
On Tue, 29 Jul 2014, Rich Shepard wrote:
CheckConstraint(org_lvl("org_lvl IN ('Federal', 'State', 'County',
'City', 'Local', 'Regional')")
Oops! that first 'org_lvl(' comes out.
Rich
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To
On Tue, 29 Jul 2014, Simon King wrote:
Hope that helps,
Simon, and others:
As a check that I understand the basics please check the syntax of this
set of three related tables:
class Agencies(Base):
__tablename__ = 'agencies'
org_name = Column(String(48), primary_key = True)
ac
On Tue, 29 Jul 2014, Simon King wrote:
Sorry, I don't know the answer to this, but based on the "attrib" example,
I would guess that the string is passed directly to the database, so you
would write something like:
agency_name.CheckConstraint("agency_name IN ('Federal', 'State',
'County', 'City
On Tue, Jul 29, 2014 at 2:40 PM, Rich Shepard wrote:
> I'm starting to learn SQLAlchemy; have 0.9.7 installed on Slackware-14.1
> with Python-2.7.5, wxPython-3.0.0.0, and postgresql-9.3.4.
>
> 1) In the docs I see a row constraint example using an integer comparison
> attrib.CheckConstraint('
18 matches
Mail list logo
