Как лучше всего хранить таблицу в БД размером Х на Y? Где кол-во столбцов может меняться, а функционал должен подрузумевать например возможности удалять строки и стобцы, а также система отката изменений.

Подойдет ли такой вариант?
users - пользователи системы
user_id - номер строки в таблице БД
...

table_properities - описания таблиц(или листов). В моем случае Лист=Таблица.
table_id - номер строки в таблице БД
table_title - название таблицы
table_author_id - номер пользователя, кто создал таблицу
table_reader_ids - список номеров через разделитель пользователей, которым разрешен просмотр таблицы в режими только для чтения
table_editor_ids - список номеров через разделитель пользователей, которым разрешено редактирование таблицы
...

table_data - содержимое ячеек таблицы
data_id - номер строки в таблице БД
data_table_id - номер таблицы table_id, к которой отнести ячейку
data_row_number(data_x как вариант) - координата х (строка) ячейки
data_col_number(data_y как вариант) - координата y (столбец) ячейки
data_content - содержимое ячейки
data_type - пока задача чисто математическая, будем считать что все данные в клетках - числа, проверку сделаем при изменении. А вообще тут могло быть enum-определение типа данных.

operation_history - история операций редактирования ячеек
operation_id - номер строки в таблице БД
operation_share_id - по умолчанию null, в случае если из таблицы удалялся столбец или строка, то в таблицу operation_history будет занесено много строк, которые взаимосвязанные. В этом случае будет сгенерирован свой уникальный operation_share_id и в каждой строке operation_share_id относящейся к операции удаления строки/столбца будет одно и то же значение
operation_table_id - таблица table_id
operation_data_id - ячейка data_id
operation_datetime - дата изменений
operation_data_old_content - старое значение ячейки в data_id

Красным цветом - экспериментальные, дополнительные возможности, не сильно приоритетны в проекте

Добавлено через 3 минуты и 53 секунды
P.S. Придумал за 5 минут

Т.е. надо хранить двумерные массивы... 
По юзерам, таблицам, данным, особых претензий нет. Только прикинь объёмы, количество операций и поток запросов - сервер справится ли?
По изменениям - плохо. Надо хранить и данные до изменения, и после. Также неплохо бы идентифицировать оператора. А вот operation_share_id мне кажется лишним... к тому же подход зависит от того, будут преобладать одиночные или пакетные изменения.
По "красному":

Вынести в отдельную таблицу прав. И никаких "через разделитель"!!!

Но вообще - дикость.