I don't know exactly what is your use case, but normally facts tables are multidimensional (e.g. Sales per geography/time/product dimension). If you have one single dimension, then all fact tables have the same cardinality and therefore you could aggregate them, but in this case that's more a question related to your specific DBMS and how it performs the retrieval of data. Having 10 different tables could make sense in some scenarios if each fact table belongs to a specific subject area and contains related facts that are rarely combined with other facts in the other fact tables. In this case you're optimizing the read operations as the entire row is relevant, rather than combining in the same row facts that are unlikely to be queried together. But it also depends how your DBMS retrieves the data. Some years ago I split a table with 400 columns and several million rows in Teradata 10, before they had built-in horizontal partitioning, because Teradata 10 was reading entire rows filling blocks of a specific size and then sending selecting the specific columns chosen. By splitting the table horizontally in several subject-area tables, I was improving the efficiency of the block reading, as practically no columns were discarded so the entire memory blocks were relevant.