ПРЕДИСТОРИЯ
Поддържам и съм в процес на реинженеринг на няколко базирани на PHP уеб приложения и има една тема, за която все още не съм намерил елегантно решение, така че търся информация, която може да ме насочи към по-добър начин за направи го.
ТЕКУЩО СЪСТОЯНИЕ
Няколко от моите приложения позволяват на потребителите да съхраняват изображения в допълнение към много данни. Всички данни завършват в PostgreSQL клъстер, но аз избирам да не съхранявам самите изображения в базата данни за производителност и поддръжка. Изображенията получават своите метаданни, съхранени в базата данни (като оригинално име на файл, ширина/височина и т.н.) и след като транзакцията на базата данни е успешна, премествам изображението във файловата система в директория с изображения (съхранена като .jpg).
ПРОБЛЕМЪТ
Всичко това функционира добре, но тъй като приложенията се използват много и от много хора едновременно и през интернет, а обработката на грешки/изключения на PHP не е най-надеждната във всички сценарии, понякога се притеснявам да не съм може да обвие съхраняването на изображението (във файловата система) в транзакцията на базата данни (тъй като се случва във файловата система). Освен това се притеснявам, защото ако файл с изображение се повреди/промени/изтрие във файловата система, записите на базата данни няма да бъдат правилно актуализирани (няма референтна цялост).
РЕШЕНИЯ
Това, което измислих досега, е:
Вариант A) Съхранявайте действителното изображение (не само метаданни, но целия двоичен файл) в базата данни. -- Не съм фен на това, тъй като в момента базата данни, въпреки че е доста сложна, все още е много малка (не повече от 60 MB). Свързаните изображения общо много много GB, така че това ще увеличи отпечатъка на моята PostgreSQL инсталация по масивен начин. Освен това, това ще усложни моите сценарии за архивиране и репликация на база данни.
Вариант B) Запазете текущия дизайн (изображения във файловата система, данни в postgres) и просто се опитайте да отчетете повредените данни на ниво приложение във всяка точка, където се използват. -- Това прави приложението много по-сложно и податливо на грешки.
Вариант В) Намерих PHP ORM рамка, наречена Flourishlib, която съдържа клас на файлова система, който симулира транзакции на файлова система (основно ако извикате $file ->rename() той проверява дали това би било възможно, но всъщност не преименува, докато не ангажирате транзакцията) -- Това е най-доброто решение, което намерих досега, но вече използвам друга ORM рамка (Propel), която ми харесва много повече за проект с такъв размер, така че ще ми трябват 2 рамки с до голяма степен припокриваща се функционалност.
Аааааа
И така, мисля, че много други хора тук ще са се сблъсквали със същия "проблем" преди и съм сигурен, че някои са измислили някои решения, за които все още не съм се сетил. Оценявайте всякакви насоки, съвети или критики.
