Има много други условия, за които съм чувал при нерелационни системи срещу релационни. Предпочитам тази терминология пред sql/no-sql, тъй като аз лично смятам, че описва разликите по-добре, а няколко от сървърите "no-sql" имат sql добавки, така че както и да е.... какъв модел на едновременност или изолация на транзакция се изисква във вашата система. Една от предполагаемите разлики между rel и non-rel dbs е "последователно-винаги", "последователно-предимно" или "последователно-евентуално". Relation dbs по подразбиране обикновено попадат в категорията „консистентно-предимно“ и с известна работа и много условия за заключване и състезание,;) може да бъде „последователно-винаги“, така че всеки винаги търси най-правилното представяне на дадена част от данните. Повечето от това, което съм чел/чувал за non-rel dbs е, че те са главно "последователни-евентуално". Това означава, че може да има много случаи на нашите данни, които се носят наоколо, така че потребител „A“ може да види, че имаме 92 джаджи в инвентара, докато потребител „B“ може да види 79 и те може да не се съгласуват, докато някой наистина не отиде да тегли неща от склада. Друг проблем е променливостта на данните, колко често трябва да се актуализират? Конкретните несвързани db, на които съм бил изложен, имат повече разходи за актуализации, някои от тях трябва да регенерират целия набор от данни, за да включат всички актуализации.
Сега имайте предвид, че не-rel/nosql са страхотни инструменти, ако наистина отговарят на вашия случай на употреба. Имам няколко, които разглеждам сега за проекти, които имам. Но трябва да разгледате всички компромиси, когато вземате решение, в противен случай то просто се превръща в по-ориентирано към автобиография развитие.
