Back in the 1980'2, when I was on ANSI X3H2, the question of whether or not to require a primary key in the table came up in the committee. Back in those days, SQL systems were based on existing file packages, which meant punch cards and magnetic tapes with a little indexing. There was no hashing to speak of, nor columnar databases nor parallel processing nor any the other things that you sort of take for granted these days (like indoor plumbing).

Did you ever wonder why the primary key is special? That at Hawaii actually has a separate syntax? That is because punch cards and tapes have to be in sorted order to work on those old filesystems. Later, Dr. Codd would allow us to have have many keys and all keys are created equal (they are all made up of not null columns and their combination is unique for each row of their table). No key is "more equal" than another key.

What we were worried about in the early days of SQL was migrating old files to the new technology. We thought about having a CREATE FILE or CREATE SOMETHING syntax in the language but decided to just keep the CREATE TABLE. This way we could put constraints on a table and fix it up after the fact without re-writing code.

Partitioning is not part of the ANSI/ISO standards, nor should it be. This is a physical storage method, and can vary from vendor to vendor. If you want to have some fun create a table with hundreds of thousands of identical rows, and then partition it. Kinda useless ain't it? Let your product partition your table by state code; one partition for California one partition for Guam, etc. I have to have some way of not putting the same customer in California and Guam at the same time. This is where key on a customer identifier is useful.

To be frank about it, when this issue came up on the committee, we never thought anybody would be sloppy enough to have a table without a key. But we thought they might inherit legacy (a.k.a. family curse) code. But surely nobody would keep it around longer than a week or two before cleaning it up!