Hot answers tagged

4

One row in a relational DB table holds one fact only. That user 12345 is connected to user 44444 and to user 55555 is two facts. Consequently it should be stored as two separate rows. Columns capture meaning from the real world. Depending on the table, there can be an implicit semantics between the columns. A good example is a departmental reporting ...


2

Generally not a good idea, for the following reasons: If someone knows UserID and times, they may be able to match that back to transactions (depending on how this ID is exposed - if it's exposed externally via an API, someone knowing UserID could generate candidate TransactionIDs from guessed times) High amount of entropy in the key means that your ...


2

While I do use NULL columns, there is overhead. The Oracle documentation you retrieved this short list should explain if you read further. There are case where NULL indicates issues with data types and/or just having the column. Consider PHONE_NUMBER NUMBER(15): This will likely have a formatted phone number column, and may be null for numbers like 1-...


1

No, you don't want to use a hash as the ID, especially if you are making the ID the Primary Key and will have tables Foreign Keyed to this table. An SHA1 hash is 20 bytes and cannot be decoded (i.e. you cannot derive the source values from it). It would be better (generally, the RDBMS being used hasn't been specified) for indexing if the values were ...


1

Indexes with the columns in the order given: actions: INDEX(user_id_to, user_id_from) -- 'covers' first query actions: INDEX(user_id_to, counter) -- may subsume ORDER BY and LIMIT in 3nd query Either index will be useful for 2nd query. DROP KEY user_id_to (user_id_to) as redundant when you add my two suggestions. For various reasons, it may be better to ...


1

Avoiding NULLs is very low on my list of optimizations. I prefer to say "use NOT NULL wherever appropriate". That implies that if you need NULL, go ahead and use it. I do find in my own tables that I rarely have a use case for NULL. See Rick's RoTs for a longer list of recommendations; they are aimed at MySQL, and come from years of optimization ...



Only top voted, non community-wiki answers of a minimum length are eligible