Multiple tables in compromised records

Hi all!

Sometimes when dealing with compromised records, there are some cases where there is a single category (record attribute) with many more instances than the rest. Take for example, 1 username and 1 password that made possible the leak of 1000 emails, IDs, and account numbers, in this case the username, password, emails, ID and accounts are all compromised records but at the moment of filling the table, this will result in 999 empty cells for username and password categories since integrates expects the same number of records for all the attributes resulting in a messy and unaesthetic table.

My question is, Would be possible to create a second compromised records table to better organize the information according to the number of instances of the information? for example, being able to create one table for username/pass and another with the rest of leaked information.

I’d love to hear your thoughts

Hi hermit-purple,

I understand your point but using the same logic. We need more than two tables. Indeed we need many tables as types we have.

What is the worst case you have seen?

Worst scenario would be similar to the one I described above, having many occurrences of an attribute and only one single occurrence of another attribute that does not fit in the same category, resulting in many unnecessary blank cells. Until now, most of the compromised records can be expressed with a MxN matrix, with most of the cells populated, but when you add a single instance of another attribute everything ends messing up, that’s the reason I think only 2 tables would do the work for now, to get rid of those singularities.