Ваше мнение? - привязка таблиц по LinkTypeId

Question

У меня есть веб-приложение, которое связывает файлы и заметки с клиентами, пользователями, проектами и т. д. Первоначально у меня были такие таблицы, как customerNote, userNote, projectNote ... и т. д.

Конструктивные соображения:
1: Я не хочу, чтобы управлять N в квадрате таблицы (более 100 customerNote, userNote, projectNote, ... customerFile, projectFile ... и т.д. таблицы)
2: Я не хочу использовать динамический SQL (TableName из LinkType)
3: Я не вижу чистый способ использования linktables (без 100+ N в квадрате linktables)

Теперь у меня есть одна нота таблицы, которая имеет LinkId и LinkTypeId. LinkId, конечно, является таблицей PK клиента | User | Project | etc; и LinkTypeId указывает на тип ссылки.

Так что:
SELECT * FROM customerNote WHERE Id = 1210
SELECT * FROM userNote WHERE Id = 3281

Теперь стало это:
SELECT * FROM Note WHERE LinkId = 1210 AND LinkTypeId = 2 (2 будучи клиентом)
SELECT * FROM Note WHERE LinkId = 3281 AND LinkTypeId = 3 (3 будучи пользователем)

Мне нравится простота этого подхода, и я завернул их в функции, которые я называю повсеместно.

Мои вопросы:
1: Без ссылочной целостности какая производительность или другие проблемы у меня есть?
2: Это вызывает проблемы с масштабируемостью?
3: Есть ли элегантное решение?

Это мой первый пост СО, и я благодарю вас всех за вашу помощь.

Answer 1

1: Без ссылочной целостности какие характеристики или другие проблемы у меня есть?

У вас возникнут проблемы со ссылочной целостностью. Вам придется либо жить с этими проблемами, либо реализовать имитацию всех ограничений ссылочной целостности в коде приложения или посредством административных процедур (например, отчетов).

Вы также значительно увеличите размер своей таблицы «примечаний». 100 тысяч строк в каждой из 100 таблиц бесплатных заметок довольно управляемы. Но 10 миллионов строк в одной таблице заметок могут заставить вас пересмотреть, стоит ли жить.

Внедрение имитации ограничений целостности в коде приложения означает, что рано или поздно кто-то (возможно, вы) пошаговое приложение и измените строки через клиент командной строки dbms или клиент gui. Вы можете сделать лот повреждений таким образом. Здравый смысл - это проверить или сбросить базу данных, прежде чем принимать такой риск, но 10 миллионов строк заметок делают менее вероятным, что вы это сделаете.

2: Это вызывает проблемы с масштабируемостью?

Он может. Если у вас есть 100 отдельных таблиц заметок, каждый из них может вырасти до 100 000 строк и по-прежнему быстро отвечать на запросы.Поместите их все в один стол, и теперь у вас есть 10 миллионов строк. И поскольку они представляют собой заметки, меньшее количество будет помещаться на странице. Это обычно означает более медленную скорость. При таком дизайне единая таблица заметок становится холодным местом (или горячей точкой, в зависимости от того, как вы на нее смотрите), замедляя каждую таблицу, в которой используются заметки, а не только одна или две сильно аннотированные таблицы.

И после того, как вы проживаете с более медленной скоростью на всех столах в течение нескольких месяцев, вы, вероятно, снова разделите эту таблицу монстров на исходные таблицы.

3: Есть ли элегантное решение?

Если каждая нота должна иметь одинаковую максимальную длину - довольно маловероятное требование для 100 столов заметок - затем создайте домен для заметок и создайте одну таблицу заметок для каждой аннотированной таблицы.

create domain note_text as varchar(1000) not null; 
create table user_notes (
    user_id integer not null references users (user_id) on delete cascade, 
    note_timestamp timestamp not null default current_timestamp, 
    user_note note_text, 
    primary key (user_id, note_timestamp) 
); 

В стороне, вам нужно быть очень внимательным, чтобы пользователи могли комментировать строки. Они часто (обычно?) Используют столбцы примечаний вместо размещения данных там, где они принадлежат. Например, если у вас есть таблица телефонных номеров пользователей, то столбец примечаний почти наверняка закончится линией данных.

Call 123-456-7890 between 8:00 am and 5:00 pm. (And that will match 
    none of this user's phone numbers.) 
Toll-free orders at 1-800-123-4567. 
He eats lunch at McDonald's on Tuesdays.