Structuring relational database tables I'm really interested in knowing what the best way to structure relational database tables in the following scenario is.

Let's say the table is recording cryptocurrency prices. There are four important aspects:

1. An ID
2. The date and time
3. What cryptocurrency it is
4. The price


I'm thinking of two possible ways to structure the resulting table, either:

ID    Date                  Crypto        Price
1     2018-01-01 12:00:00   BTC           100000
2     2018-01-01 12:00:00   ETH           1234


Or

ID    Date                  BTC_Price    ETH_Price....
1     2018-01-01 12:00:00   1000000      1234


Is there a "best practice" to structure these kind of tables? One consideration that I have is I might want to add more types of currencies in this case. I can do this with the ALTER command, but in that context the first layout makes more logical sense to me.

What are your thoughts?
Your first example is considerably better than your second.  It is a standard rule to not use repeating groups of fields and to break fields down to their smallest meaningful value.  BTC_Price and ETH_Price are not broken down to their smallest meaningful value; price and crypto.  In the first example you separated the crypto from price.  This is the correct thing to do.  Joe is also correct in that you should have another table to hold the different kinds of cryptocurrencies with a auto incrementing primary key.  This is often referred to as a lookup table.

Have a look at database normalization and learn about what are called "normal forms".  Your first table conforms with what is called "3rd normal form" and your second table conforms with I believe "2nd normal form".  Typically the higher the normal form the better but 3rd normal form is considered the standard that you should attempt to achieve at minimum.