Зависит от того, как вы хотите получить к нему доступ.
Как вы говорите, скорость важна - но что вы собираетесь делать с этими дополнительными, необязательными частями информации? Вам нужно хранить их вообще? Предполагая, что вы делаете, как часто вам нужно получить к ним доступ?
По сути, если вам всегда нужно будет хотя бы проверить, есть ли они там, возможно, лучше поместить их в один стол. Если вам все равно нужно проверить, возможно, вам придется покончить с этим как часть первоначального запроса.
Если, с другой стороны, вы обычно можете бегать, не удосужившись проверить эти дополнительные куски, и вам нужно беспокоиться только по специальному запросу, тогда может быть лучше поместить их в другую таблицу. Объединение (или последующий поиск) будет дорогостоящим - намного дороже, чем извлечение нулей для пустых столбцов - но если оно очень редкое, вероятно, будет стоить дешевле при выполнении во время выполнения в долгосрочной перспективе.
Также следует помнить о компромиссе в терминах хранения и транспорта: для хранения большого количества пустых полей требуется некоторое пространство, а для отправки большого количества пустых полей требуется пропускная способность сети.
Если дисковое пространство не имеет значения, но пропускная способность ограничена, сделайте приложение тщательно разработанным для минимизации ненужных поисков, а затем с помощью сложных запросов вы можете хранить дополнительные (необязательные) данные, но не передавать их обратно, если они не запрошены.
Итак, все действительно зависит от того, что важно для вас. Как только вы узнаете, какие у вас основные проблемы с дизайном, вы поймете, какие компромиссы следует предпринять для решения этих проблем за счет других. Балансирующий акт.