Comments on: Connecting to postgresql from a range of different front-ends http://www.archaeogeek.com/blog/2008/06/09/connecting-to-postgresql-from-a-range-of-different-front-ends/ Travels in a digital world Wed, 08 Feb 2012 13:03:07 +0000 hourly 1 http://wordpress.org/?v= By: admin http://www.archaeogeek.com/blog/2008/06/09/connecting-to-postgresql-from-a-range-of-different-front-ends/comment-page-1/#comment-24925 admin Wed, 18 Jun 2008 10:44:15 +0000 http://www.archaeogeek.com/blog/?p=143#comment-24925 Hey ChrisW, Thanks for the rant! In general I agree with you- but... with my comment I was thinking of lookup tables. Since all they are doing is providing values for dropdown lists and such like, they are not really part of the relational database because you don't relate data in your main tables to them- you wouldn't want cascading updates or deletes, and as such you can get away without a primary key. In general I would always include one, but I don't think in those cases it's totally necessary. Everything else though- agreed! Hey ChrisW, Thanks for the rant! In general I agree with you- but… with my comment I was thinking of lookup tables. Since all they are doing is providing values for dropdown lists and such like, they are not really part of the relational database because you don’t relate data in your main tables to them- you wouldn’t want cascading updates or deletes, and as such you can get away without a primary key. In general I would always include one, but I don’t think in those cases it’s totally necessary. Everything else though- agreed!

]]> By: ChrisW http://www.archaeogeek.com/blog/2008/06/09/connecting-to-postgresql-from-a-range-of-different-front-ends/comment-page-1/#comment-24754 ChrisW Sat, 14 Jun 2008 15:33:32 +0000 http://www.archaeogeek.com/blog/?p=143#comment-24754 "always include a primary key in any tables you expect people to select or edit data in" As a database developer, I'd go a little further and emphasise that you really must define a primary key for *every* table in a relational database such as Postgres, Oracle etc. This is a fundamental requirement of the relational database model - if you can't define a way to identify each row in your table uniquely (the PK) then you haven't finished normalising the data in the first place. From a practical point of view, many DB tools expect you to have performed this basic step and may not work properly without a PK for each table. For example, the DB itself can use your PK definition to make sure you don't accidentally create duplicate rows in a table. Also, PKs are typically indexed by default, so defining a PK will also speed up access to the data. Other tools, such as Java DB interfaces using Hibernate etc, will not work without a PK for each table. Similar arguments apply to foreign keys i.e. when you include the PK of a row from table A inside a record in table B, so you can relate the "child" data in B back to its "parent" row in A. Defining a foreign key allows the DB to check that the parent row exists when you try to add a child record, so you can avoid creating "orphaned" data. Also, the DB can enforce extra rules based on the FK e.g. warning you if you try to delete a parent record which still has children, or "cascading" the delete to remove the children as well as the parent. And FKs are usually good candidates for indexing, as you often search for data using them, and indexing FKs will often speed up your DB access. Again, this is a fundamental part of relational DB design: if you haven't done this, you haven't got a proper database, just a bunch of unrelated data. Sorry to rant, but I've encountered too many "databases" where people have simply dumped their spreadsheets into an RDBMS without bothering to create a basic relational data model first (e.g. work out what the keys are for each table), then complain because their "database" is too slow, filled with rubbish/duplicate rows/orphans etc. But I feel much better now. “always include a primary key in any tables you expect people to select or edit data in”

As a database developer, I’d go a little further and emphasise that you really must define a primary key for *every* table in a relational database such as Postgres, Oracle etc. This is a fundamental requirement of the relational database model – if you can’t define a way to identify each row in your table uniquely (the PK) then you haven’t finished normalising the data in the first place.

From a practical point of view, many DB tools expect you to have performed this basic step and may not work properly without a PK for each table. For example, the DB itself can use your PK definition to make sure you don’t accidentally create duplicate rows in a table. Also, PKs are typically indexed by default, so defining a PK will also speed up access to the data. Other tools, such as Java DB interfaces using Hibernate etc, will not work without a PK for each table.

Similar arguments apply to foreign keys i.e. when you include the PK of a row from table A inside a record in table B, so you can relate the “child” data in B back to its “parent” row in A. Defining a foreign key allows the DB to check that the parent row exists when you try to add a child record, so you can avoid creating “orphaned” data. Also, the DB can enforce extra rules based on the FK e.g. warning you if you try to delete a parent record which still has children, or “cascading” the delete to remove the children as well as the parent. And FKs are usually good candidates for indexing, as you often search for data using them, and indexing FKs will often speed up your DB access.

Again, this is a fundamental part of relational DB design: if you haven’t done this, you haven’t got a proper database, just a bunch of unrelated data.

Sorry to rant, but I’ve encountered too many “databases” where people have simply dumped their spreadsheets into an RDBMS without bothering to create a basic relational data model first (e.g. work out what the keys are for each table), then complain because their “database” is too slow, filled with rubbish/duplicate rows/orphans etc.

But I feel much better now.

]]>