Re^2: Architecture design for full stack development.

There are good reasons to prevent gaps. One is that otherwise there is a security lookhole - an attacker can force your sequence to hit the limit over time if you allow gaps creating denial of service. The limit depends on the size of the integer, so is not so accessible for bigint, but I use sequences even on smallint PKs for some cases where I don't even want the number of values to exceed a low ceiling. It just isn't good maintainability thinking to let gaps multiply like rabbits if one expects a lot of activity with users allowed to delete, insert and maintain records. For clustered indexes it will ultimately have exactly the same effect has fragmented blocks on a disk.

In regard to why this prompts an ORM, looks like from posts I wasn't clear in the OP... The moment I have to consider using SQL for dealing with something across multiple tables (pks have fks in other tables), embedded in my Perl, is the moment where I need an ORM. It has nothing to do with the particular issue of keys, it is just that if not this requirement that another requirement is bound to come along that prompts awkward-maintenance use of embedded SQL best factorised into an ORM instead.

One world, one people

Comment on Re^2: Architecture design for full stack development.

Replies are listed 'Best First'.
Re^3: Architecture design for full stack development. by Mr. Muskrat (Canon) on Jun 26, 2017 at 15:24 UTC
Thanks for the follow up on why you need an ORM. If you're concerned about an attacker then take steps to harden your system (not just the database). If you're concerned about running out of values for a sequence then you should consider non-integer approaches; one such approach would be UUIDs.	[reply]
Re^4: Architecture design for full stack development. by erix (Prior) on Jun 28, 2017 at 09:44 UTC
... you should consider non-integer approaches; one such approach would be UUIDs. Possible, but then you might hit this: biginteger-vs-uuid inserts (image) There are ways to avoid that but let's wait till the OP gets a site up, and reaches, say, 10 tps. It may never happen, 'beginners'* often have unrealistically high hopes for their unborn brainchild. Well-trodden paths are boring, and often safest. *) Obviously, 'beginner' here in the sense of beginning a system (as OP says: 'a website from scratch')	[reply]