Внешние ключи это правильно и хорошо. При их наличии можно впринципе ничего не мониторить, а поставить каскадное удаление/обновление. Подводных камней почти нет, есть нюансы:
1. Замедление операций работы со связанными записями
2. Необходимость расстановки индексов на оба конца связи
Все правильно написал, только слишком эмоционально 8)
А если родной очень сложен то и браться лучше не надо. БД не то место куда нужно лезть всем подряд, хотя я денежку периодами получаю на фиксах за теми кто туда лезет без знаний)
А если родной код понимается то легко делается обертка: $db->getAll('query ? param text', $someVar);
он при том, что я нахожу случаи когда меня уже сам фреймворк не устраивает.
Контрибьютить да, сам вот иногда отдаю скрипт нахаляву, а чтобы выложить это нужно код причесать, закоментить, к тому же иногда фанаты ООП налетают, которых я уста уже разочаровывать.
ЗЫ есть еще одна проблема у меня, в примере выше подцеплен jQuery, Angular и и еще много милых и хороших js файлов, а выводим таблицу с фикс хедером? Когда я такое вижу у меня волосы шевелятся везде и я делаю тоже самое на нативном js за 15 минут.
Суть задачи в изначальном посте. Нет вопросов чтобы сделать свое. Но когда ты взял взял таблицу
+фикс хедеры - нашел
+ нужно следить за актуальностью данных - нашел
+ сделать каждую строку/столбец интерактивной - дописал
Вот как только пошли сплошные дописал - фреймворк в лес уходит.
Зачем ваять если уже все сваяно?) Я честно пытался использовать сложные фреймворки но каждый раз, внося в него 100500ое изменение под себя, отказывался и забывал. Наглядный пример: динамические таблицы с фикисрованным хедером: то что есть в публичном доступе заставляет плакать крвоавыми слезами, посему пришлось ваять свое в итоге она выросла в подобие google spreadsheets без формул.
Тестами покрывать не планирую. За остальное благодарю, буду чтить.
По отдельности ненужно ибо самая больная часть это как раз динамические изменение данных и соответственно отслеживание таких изменений.
