The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года , opennews (?), 04-Янв-24, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


198. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  +/
Сообщение от adolfus (ok), 06-Янв-24, 17:39 
Два и более одновременно работающих пользователя с базой данных в любом случае требуют блокировок и сериализации доступа, а работа с двумя и более таблицами в любом случае требует ACID-транзакций.
В противном случае практически сразу базу запорете.
Не, можно использовать b однопользовательские СУБД, но придется самому реализовывать все алгоритмы "читатели-писатели", семафоры, мьютексы и и прочие сериализационные кунштюки. Но только, если язык вашей субд это позволяет. Инасе придется все операторы вашей СУБД обернуть в функции си или сикрос-крос, чтобы задействовать многопользовательские механизмы posix.
Ответить | Правка | Наверх | Cообщить модератору

205. "Рейтинг популярности СУБД. PostgreSQL назван СУБД 2023 года "  +/
Сообщение от Аноним (205), 09-Янв-24, 01:24 
Ну не, не всё так сложно. Вернее, некотрые сложности РСУБД можно избежать.
Классические реляшки опираются на то, что в любой момент есть несколько клиентов, каждый из которых может запустить любую операцию CRUD и каждая операция не должна тормозить. Поэтому приходится выворачиваться на полную катушку со всеми подкапотными хитростями.

Для "маленького офиса"(SOHO) мы можем допустить:

1. Клиенты пишут в базу редко и быстро (создание документов, какие-то мелкие логи). Что позволяет блокировать таблицу ДЛЯ ВСЕХ операций без дополнительных трюков. Лок, запись, анлок.
2. Соотв. чтение может ну совсем иногда подтормаживать, но в целом работает быстро - нет никаких "слепков базы", "транзакций чтения" и т.п. Что видит один клиент, видят все.
3. Подразумеваем, что мы работаем в стабильной среде - т.е. есть электричество и никто в середине записи не дёрнет рубильник. Собственно, так и работает ЛЮБОЙ современный сервер - как минимум на UPS, как максимум - на генераторе.

Зная всё это, можно сильно упростить все операции с таблицами и трансформировать работу с реляционной базой - таблицы останутся реляционными, но метод работы с ними будет как у FoxPro - "мануальный": "Считать все записи таблицы", "пройтись по записям, сохранить в переменной все зарплаты", "взять запись, найти записи в другой таблице, зависящие от этой, удалить".

Это просто как пример операций, НО(!) сложные запросы перестанут быть "сложнодекларативными" - они станут ИМПЕРАТИВНЫМИ (что сильно упростит код программиста для алгоритмически тривиальных задач а-ля "найти все города, где люди выше среднего и в музыке любят рок").

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру