Design of tables with large optional fields?

I have a general SQL design-type question.

I want to log errors to a table. If the error is with a URL, I want to store the URL. These URLs can be very large, hundreds of characters, but I only need to store it if it causes the error, which should be very infrequent. Which is the better design:

Create a large varchar field in the log table to hold the URL, or null if the error wasn't with the URL.

Create a foreign key field in the log table to a second URL table, which has a unique ID and a large varchar, and only create a record in this table if the error is with the URL.

One concern I have with design 2 is that there could be many other fields that are infrequent. Do I create a separate table for every one?

Richard

There is no right solution I think, only the one you feel most comfortable with.
You should avoid NULL columns but it is not always possible.|||After significant research, the definitive answer seems to be to create a separate table with a column for the optional data and a foreign key column to the original table. You can access all the optional values with a view or outer join.