1. INT32 is fairly natural and generally a default goto in most higher level languages that, you know, actually USE the data... anything smaller, or larger than INT32 should be discouraged unless absolutely necessary... Yes, storage should be considered, but you also need to consider the friction such design can cause with different client languages. Beyond this, you can go with Unsigned values, but again, this can cause a lot of friction.
2. This is precisely why I don't like my RDBMS talking directly to each other. In fact, I like my RDBMS to be as stupid as possible. As mentioned above, the most common structure to your programming environment is likely what you should use... for time insensitive date/time I always store/read in UTC offset, same goes across boundaries. For events, I use the local time (no offset specified) and/or with the location or offset. It depends on the use.
3. Most databases that support UUID/GUID fields support a generator that will create an index friendly sequential UUID, where the main portion is sequential, with most of the value still random.
UUIDs are essential for many offline access/creation, synchronization and sharding systems. The biggest mistake a DBA tends to make is to assume that a single server will run everything well enough for everyone that uses a given application.
4. I tend to always have primary and foreign key constraints.. additional indexes should only be considered once you have typical use cases in place. After you have done the necessary profiling to determine which indexes will be the most benefit.
I would state that not understanding how indexes work in your given RDBMS can be a big issue. I think MSSQL tends to be one of the most forgiving in this area, and Oracle least so.
5. (see my response to number 4)
The arguments for 1, 2, 3 are argumentative at best.. there are perfectly good use cases for using a datatype larger than necessary (reducing friction in code is huge), not to mention UUIDs being absolutely essential in many use cases. MSSQL with create a UUID field, and a unique constraint when you enable replication if a table doesn't already have it for example, so it may as well be a primary key, if it makes sense.
As to 4-5, this comes down to understanding index strategies, which is a separate learning issue imho.
2. This is precisely why I don't like my RDBMS talking directly to each other. In fact, I like my RDBMS to be as stupid as possible. As mentioned above, the most common structure to your programming environment is likely what you should use... for time insensitive date/time I always store/read in UTC offset, same goes across boundaries. For events, I use the local time (no offset specified) and/or with the location or offset. It depends on the use.
3. Most databases that support UUID/GUID fields support a generator that will create an index friendly sequential UUID, where the main portion is sequential, with most of the value still random.
UUIDs are essential for many offline access/creation, synchronization and sharding systems. The biggest mistake a DBA tends to make is to assume that a single server will run everything well enough for everyone that uses a given application.
4. I tend to always have primary and foreign key constraints.. additional indexes should only be considered once you have typical use cases in place. After you have done the necessary profiling to determine which indexes will be the most benefit.
I would state that not understanding how indexes work in your given RDBMS can be a big issue. I think MSSQL tends to be one of the most forgiving in this area, and Oracle least so.
5. (see my response to number 4)
The arguments for 1, 2, 3 are argumentative at best.. there are perfectly good use cases for using a datatype larger than necessary (reducing friction in code is huge), not to mention UUIDs being absolutely essential in many use cases. MSSQL with create a UUID field, and a unique constraint when you enable replication if a table doesn't already have it for example, so it may as well be a primary key, if it makes sense.
As to 4-5, this comes down to understanding index strategies, which is a separate learning issue imho.