База данных для маленькой программы продаж/склада

[WAYFARER]

Т.е. я создал нового юзера с таким же именем, но другой сетью. Присвоил ему такие же привелегии. Старого удалил.
Вроде работает. Наверное чужие для хищников придумывали такое

А зачем пересоздавать пользователя?

[debi12345]

MySQL, тоже позволяет создавать/выполнять какие-то функции.

Основная фишка - удобное стандартизованное API для написания собственных функции на C. Очень сильно облегчает тему с выделением-освобождением динамической памяти, особенно под строки.

1) Правильно ли я понял, что, в MySQL, за это отвечает свой собственный движок, который вначале парсит текст, а потом выполняет функции, а в Postgre это всё делается минуя парсер?

Нединамический код PostGRes компилирует, динамический (скриптовые эвалюации) код - выполняет напрямую. Если используются параметрические запросы,то SQL ессно скомпилируется. Функции, результат которых зависит только от аргументов (cacheable-immutable), вычисляет один раз - потом возвращает результаты из кэша.

ПС: почему PostgreSQL "сложен" ? Он как раз акцентирован на совместимости с SQL-станадртами, практически никаких нюансов - читаешь доку на стандарты и вуаля.

[stanilar]

Sqlite слишком ограничена и не может работать в качестве сервера

Вот именно под дельфей есть проект mormot, который позиционируется как сервер+орм, судя по авторским тестам - проект может иметь большое будущее. Орм может работать и с птицей.

[debi12345]

Sqlite слишком ограничена и не может работать в качестве сервера

Ничто не мешает написать компонент-диспетчер соединений-запросов к SQLITE, если вдруг потребуется уйти с 1-пользовательского режима.

[azsx]

Многие программисты обожают и восхваляют Postgre. Но я пока не вижу реальных плюсов, которые делают Postgre сильнее или быстрее.

например, у него версионная модель данных. Значительно безопаснее мускула на дохлых компах. Хотя в целом вы правы, как сильно Postgre начинал и как мало он сделал. ээх...

[Снег Север]

Ничто не мешает написать компонент-диспетчер соединений-запросов к SQLITE, если вдруг потребуется уйти с 1-пользовательского режима.

Никто не мешает написать кривой самопальный сервер, который использует SQLITE в качестве хранилища. Остается единственный вопрос - зачем, если есть отличные готовые сервера?

[resident]

А зачем пересоздавать пользователя?

Вот и я о том же. Или я чего-то не понимаю, или под спайсом придумывали этот MySQL.
Функция GRANT - это функция создания пользователя. Маску подсети она не меняет. И если я в неё передаю уже существующее имя, но с новой подсетью, то создается новый пользователь. А старый куда? Пришлось удалить.

Пример: есть пользователь captain с адресом 111.111.111.111, делаю GRANT ему на 222.222.222.222. И в системе имею уже двух пользователей - новый и старый, который уже лишний и его приходится удалять.

Код: Выделить всё

mysql> CREATE USER captain@'111.111.111.111';
Query OK, 0 rows affected (0.01 sec)

mysql> GRANT ALL PRIVILEGES ON prestadb.* TO captain@'222.222.222.222';
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT user, host FROM mysql.user WHERE user='captain';
+---------+-----------------+
| user    | host            |
+---------+-----------------+
| captain | 111.111.111.111 |
| captain | 222.222.222.222 |
+---------+-----------------+
2 rows in set (0.00 sec)


If an account named in a GRANT statement does not already exist, GRANT may create it...

[vitaly_l]

Пример: есть пользователь captain с адресом 111.111.111.111, делаю GRANT ему на 222.222.222.222. И в системе имею уже двух пользователей - новый и старый, который уже лишний и его приходится удалять.

Пользователь в MySQL - это какой-то постоянный "клиент" или ещё точнее "постоянный доступ", который создают один раз и надолго. Если Вам нужно подключить несколько человек, то всех их подключаете под этим пользователем(доступом). То есть, пользователь MySQL - это именно доступ к базе по сверхсекретной паре логин пароль, которая хранится исключительно на сервере...

А вот самим людям, доступ, даёте уже создав и потом взяв пароль логин из какой-нить таблицы своей базы.


.

[resident]

Пользователь в MySQL - это какой-то постоянный "клиент" или ещё точнее "постоянный доступ", который создают один раз и надолго. Если Вам нужно подключить несколько человек, то всех их подключаете под этим пользователем(доступом).

После Postgres, в котором есть роли, я ваш подход иначе как извращенством не назову.
В базе и должна быть туча пользователей под ролями, а не один. Получается и Row-level security опять же для ролей или пользователей в MySQL отсутствует.
https://habrahabr.ru/post/264281/

один раз и надолго

Вот прошло "долго" и мне потребовалось узнать ответ на вопрос, на который вы не отвечаете:
Как же сменить сеть пользователю?
viewtopic.php?f=31&t=11006&start=30#p95079
Пока, кроме как созданием нового пользователя и уничтожением старого, решения не вижу. Но это создание, а не изменение.

[vitaly_l]

Пока, кроме как созданием нового пользователя и уничтожением старого, решения не вижу.

В этой ситуации можно создать один единый доступ для всех 255*255 user-ов из одной подсети.
Затем создать второй единый доступ для всех 255*255 user-ов из второй подсети.
Затем создать третий единый доступ для всех 255*255 user-ов из третьей подсети.
Больше в MySQL никак сократить нельзя, это что-то на подобии ролей. Но я пока только смотрю "Ваше" очень интересное кино про Postgres.
Возможно там есть возможность ОБНОВИТЬ данные по подсетям доступа, при смене провайдера или хостинга? (хотя это тоже самое, что у удалить и создать заново)

Добавлено спустя 55 минут 555 секунд:
При этом, все пользователи заходят в базу, под своим паролем и логином, но к серверу МОЖЕТ подключается вообще единый для всех серверный "доступ". А отсеивание по МАСКЕ и ПОДСЕТИ - может и должно, происходить задолго ДО подключения к базе данных.


.

[resident]

Возможно там есть возможность ОБНОВИТЬ данные по подсетям доступа, при смене провайдера или хостинга?

Хоть пользователям, хоть целым ролям. Тут тоже зачем-то задумано, что "один раз и надолго" - доступа из SQL я пока не нашел, только править конфиги руками.
1) В конфиге postgresql.conf задать, какие адреса слушать
2) В конфиге pg_hba.conf уже подробно задать ролям (поставить знак плюс перед ролью) и(или) пользователям кто, куда, откуда и как.

Код: Выделить всё

Example 19-1. Example pg_hba.conf Entries

# Allow any user on the local system to connect to any database with
# any database user name using Unix-domain sockets (the default for local
# connections).
#
# TYPE DATABASE USER ADDRESS METHOD
local all all trust

# The same using local loopback TCP/IP connections.
#
# TYPE DATABASE USER ADDRESS METHOD
host all all 127.0.0.1/32 trust

# The same as the previous line, but using a separate netmask column
#
# TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD
host all all 127.0.0.1 255.255.255.255 trust

# The same over IPv6.
#
# TYPE DATABASE USER ADDRESS METHOD
host all all ::1/128 trust

# The same using a host name (would typically cover both IPv4 and IPv6).
#
# TYPE DATABASE USER ADDRESS METHOD
host all all localhost trust

# Allow any user from any host with IP address 192.168.93.x to connect
# to database "postgres" as the same user name that ident reports for
# the connection (typically the operating system user name).
#
# TYPE DATABASE USER ADDRESS METHOD
host postgres all 192.168.93.0/24 ident

# Allow any user from host 192.168.12.10 to connect to database
# "postgres" if the user’s password is correctly supplied.
#
# TYPE DATABASE USER ADDRESS METHOD
host postgres all 192.168.12.10/32 md5

# Allow any user from hosts in the example.com domain to connect to
# any database if the user’s password is correctly supplied.
#
# TYPE DATABASE USER ADDRESS METHOD
host all all .example.com md5

# In the absence of preceding "host" lines, these two lines will
# reject all connections from 192.168.54.1 (since that entry will be
# matched first), but allow GSSAPI connections from anywhere else
# on the Internet. The zero mask causes no bits of the host IP
# address to be considered, so it matches any host.
#
# TYPE DATABASE USER ADDRESS METHOD
host all all 192.168.54.1/32 reject
host all all 0.0.0.0/0 gss

# Allow users from 192.168.x.x hosts to connect to any database, if
# they pass the ident check. If, for example, ident says the user is
# "bryanh" and he requests to connect as PostgreSQL user "guest1", the
# connection is allowed if there is an entry in pg_ident.conf for map
# "omicron" that says "bryanh" is allowed to connect as "guest1".
#
# TYPE DATABASE USER ADDRESS METHOD
host all all 192.168.0.0/16 ident map=omicron

# If these are the only three lines for local connections, they will
# allow local users to connect only to their own databases (databases
# with the same name as their database user name) except for administrators
# and members of role "support", who can connect to all databases. The file
# $PGDATA/admins contains a list of names of administrators. Passwords
# are required in all cases.
#
# TYPE DATABASE USER ADDRESS METHOD
local sameuser all md5
local all @admins md5
local all +support md5
# The last two lines above can be combined into a single line:
local all @admins,+support md5
# The database column can also use lists and file names:
local db1,db2,@demodbs all md5

Добавлено спустя 3 минуты 20 секунд:

хотя это тоже самое, что у удалить и создать заново

Как же тоже самое? При создании заново вам потребуется припомнить и пароль и все заданные права.
А при изменении не нужно помнить ничего, просто изменить адреса и всё.

Добавлено спустя 17 минут 50 секунд:

А отсеивание по МАСКЕ и ПОДСЕТИ - может и должно, происходить задолго ДО подключения к базе данных.

Пожалуй не соглашусь. Хотелось бы, чтобы именно база отбрыкивалась в зависимости от комбинации роль/сеть.
Вот к примеру, увели у вас пароль или еще какой страшный сон представим. Или вот делаю программу и вшил туда свой пароль, так же как и пароль немцев. Отправляю им копию проги без страха.
Они из своей сети, даже зная пароль, не могут подсоединиться под моей ролью, т.к. себе я разрешил соединятся только с сети Ростелеком-а.

[WAYFARER]

Пока, кроме как созданием нового пользователя и уничтожением старого, решения не вижу. Но это создание, а не изменение.

На вашем примере. Если вы не хотите давать доступ пользователю из разных сетей/с разных ip а хотите просто изменить хост, то сделайте так:

Код: Выделить всё

UPDATE mysql.user
    SET host='222.222.222.222'
    WHERE User = 'captain'  AND host = '111.111.111.111';
FLUSH PRIVILEGES;

Добавлено спустя 2 минуты 42 секунды:

Пример: есть пользователь captain с адресом 111.111.111.111, делаю GRANT ему на 222.222.222.222. И в системе имею уже двух пользователей - новый и старый, который уже лишний и его приходится удалять.

Фактически это надо понимать так: вы разрешаете пользователю подключаться не только с 111.111.111.111, но и 222.222.222.222. Если вы хотите что бы пользователь хотел подключаться только с 222.222.222.222 а с 111.111.111.111 не мог - отредактируйте значение host этому пользователю.

[vitaly_l]

Пожалуй не соглашусь. Хотелось бы, чтобы именно база отбрыкивалась в зависимости от комбинации роль/сеть.

Например все роботы будут обращаться напрямую к базе - это чревато, чем-то, вроде "случайной" dDos атаки. Ну а если к базе захотят подключиться реальные хакеры, то, они там используют всякие хитрые приёмы позволяющие вывести базу из строя и после этого взломать. Поэтому, лучше отсекать всех "чужих", задолго до подключения к базе. Даже, если отсечение будет дублировать подключение. Всё зависит от серьёзности Вашего заказчика.


.

[debi12345]

Хотелось бы, чтобы именно база отбрыкивалась в зависимости от комбинации роль/сеть.

??? Файрволы на порядок надежнее по этой части - поэтому на них и делают разграничение по IPшникам-портам.

[resident]

а хотите просто изменить хост, то сделайте так

Если этого достаточно, то Ок

Файрволы на порядок надежнее

И файрвол тоже использовать. Кого пустит файрвол уже далее будет рассматриваться базой на соответствие роль/сеть. Если уж создатели MySQL или Postgres придумали такую возможность, то почему бы не воспользоваться?