Re^4: Perl DBI and Foreign Keys

I am under the impression that if a field is not AUTO_INCREMENT then it expects you to fill its value or it will take its default value if any.
Well... Not exactly...consider this code..

#!/usr/bin/perl
use strict;
use warnings;
use DBI;

my $dbfile = "whatever.sqlite";

my $dbh = DBI->connect("dbi:SQLite:dbname=$dbfile","","",{RaiseError =
+> 1})
    or die "Couldn't connect to database: " . DBI->errstr;


$dbh->do ("CREATE TABLE ScoreCard
             ( 
                Url       varchar(80)   DEFAULT '',
                DateTime  varchar(20)   DEFAULT '1995-12-30 00:00:01',
                Desc      varchar(100)  DEFAULT ''
             );
          ");

$dbh->do ("CREATE TABLE Participants
             (  id      integer PRIMARY KEY AUTOINCREMENT,
                Url     varchar(80)  ,
                Name    varchar(10)  DEFAULT ''
             );
          ");
[download]

You will see that the ScoreCard table winds up containing an extra field, "rowid" that I didn't specify in CREATE TABLE ScoreCard. Note: You need a program to show the actual created DB fields. That is a unique id that SQL will assign on it own. In the Participants TABLE, that field doesn't exist because I called it "id" and gave some rules for this PRIMARY KEY.

I did take a look at your article and am still thinking about it. I did have to burst out laughing at this part:
"We don’t want our complexity to grow linearly as we add more functionality into the system, which would drastically slow us down as we grow in the eyes of both business and value confidence." My gosh we only wish that complexity grew linearly with functionality. Complexity appears to grow exponentially with functionality. What does "growing in the eyes of value confidence" mean? What!?

Comment on Re^4: Perl DBI and Foreign Keys Download Code

Replies are listed 'Best First'.
Re^5: Perl DBI and Foreign Keys by soonix (Chancellor) on Apr 08, 2019 at 14:32 UTC
You will see that the ScoreCard table winds up containing an extra field, "rowid" that I didn't specify in CREATE TABLE ScoreCard. That is SQLite specific, documented under https://sqlite.org/lang_createtable.html#rowid Except for WITHOUT ROWID tables, all rows within SQLite tables have a 64-bit signed integer key that uniquely identifies the row within its table. … BTW SQLite's `last_insert_rowid()` documentation explicitly refers to "the database connection which invoked the function", so should work with multiple parallel insertions.	[reply] [d/l]
Re^6: Perl DBI and Foreign Keys by dsheroh (Monsignor) on Apr 09, 2019 at 07:27 UTC
Yeah, `rowid` is SQLite-specific, but most^{[citation needed]} major database engines will generate some kind of hidden unique identifier for each row if there isn't one explicitly specified. I believe this is because it's much harder to implement joins between tables which completely lack any way to uniquely identify rows. (I read something along those lines many years ago, but haven't really looked into it in any detail.) IIRC, MySQL and Postgres use UUIDs for this purpose and, of course, the field names involved will be engine-specific (if they're user-accessible at all).	[reply] [d/l]