1) Нужно ли использовать регулярные выражения для столбцов во время проектирования таблицы? Насколько это сильно замедляет операции вставки?
CREATE TABLE emails (
ID serial constraint users_pk primary key,
email varchar
CONSTRAINT proper_email CHECK (email ~* '^[A-Za-z0-9._%-]+@[A-Za-z0-9.-]+[.][A-Za-z]+$')
);
create unique index users_email_uindex
on users (email);
2) Я бы хотел, чтобы ID и у всех пользователей был реальным, то есть чтобы значение ID не увеличилось тогда, когда INSERT не сработал. То есть если ID последнего пользователя = 10, то это значит, что у меня ровно 10 пользователей.
Правильный ли это подход?
3) Я бы хотел добавлять пользователя в таблицу одним запросом, потому что если такой пользователь уже существует я просто получу нужный код ошибки, а не проверять сначала существует ли пользователь в таблице, а потом его добавлять, это уже два запроса.
Так делать можно и правильно?
Где я могу почитать про общие концепции создания хороших таблиц для эффективной, а главной безопасной работы с данными?
SQL
PostgreSQL - концепция хранения данных
1. Не особо замедляет, просто в этом нет смысла. Эту проверку должно выполнять приложение. Может оказаться, что твоё регулярное выражение отбрасывает правильные адреса.
2. Неправильный подход. В некоторых случаях можно использовать натуральный ключ, например ИНН. Но тогда ИНН должен быть обязательно заполнен, и его нельзя будет изменить (или изменять будет сложно). Можно использовать логин пользователя.
3. Для этого в таблице должен быть натуральный ключ (см. предыдущий пункт). Он может не совпадать с первичным ключом. Должно быть ограничение уникальности по натуральному ключу (например, по логину пользователя)
4. Есть книги по проектированию баз данных. PostgreSQL - это одна из реляционных СУБД. Общие принципы одинаковы для всех СУБД этого типа.
2. Неправильный подход. В некоторых случаях можно использовать натуральный ключ, например ИНН. Но тогда ИНН должен быть обязательно заполнен, и его нельзя будет изменить (или изменять будет сложно). Можно использовать логин пользователя.
3. Для этого в таблице должен быть натуральный ключ (см. предыдущий пункт). Он может не совпадать с первичным ключом. Должно быть ограничение уникальности по натуральному ключу (например, по логину пользователя)
4. Есть книги по проектированию баз данных. PostgreSQL - это одна из реляционных СУБД. Общие принципы одинаковы для всех СУБД этого типа.
1) если нужно, то нужно ^_^ дело в том, что в общем случае одну базу могут теребить несколько клиентов, иногда даже написанных несколькими поколениями программистов, поэтому, чтобы обезопасить себя от зоопарка, какие-то проверки в базе должны быть.
2) это неправильно. id - это не номер по порядку. id должен обеспечивать уникальность, и всё. больше того, если вдруг потребуется репликация базы, возможны рамсы с одинаковыми id в разных копиях (поэтому sql server, например, при настройке репликации создаёт в каждой таблице доп. столбец с guid-ами). по личному опыту скажу, что удобны uuid-ы (кто-то говорит, что это оверкилл, но это не так).
(к слову, инн, по крайней мере, с юриками - плохая идея, поскольку есть конторы с дочками с одним инн на всю толпу)
3) объедини эту логику в хранимую процедуру и дёргай её.
2) это неправильно. id - это не номер по порядку. id должен обеспечивать уникальность, и всё. больше того, если вдруг потребуется репликация базы, возможны рамсы с одинаковыми id в разных копиях (поэтому sql server, например, при настройке репликации создаёт в каждой таблице доп. столбец с guid-ами). по личному опыту скажу, что удобны uuid-ы (кто-то говорит, что это оверкилл, но это не так).
(к слову, инн, по крайней мере, с юриками - плохая идея, поскольку есть конторы с дочками с одним инн на всю толпу)
3) объедини эту логику в хранимую процедуру и дёргай её.
Махсут Темирбеков
Аглая, посылай всех читать Грабера. Это успокаивает.
нужно начинать с того, чтобы четко описмть, ЧТО нужно.
а потом обсуждать КАК
а потом обсуждать КАК
1. Я бы проверяла в приложении, такая логика имеет свойство меняться.
2. Хотел бы - это понятно, не понятно, зачем?
3. в postgressql есть "уникальные индексы", которые как раз выполняют такую задачу, чтобы в колонке данные были уникальные. К примеру, если у вас есть таблица пользователей, с полями id(генерируется бд), username, то можно создать уникальный индекс на поле username. Тогда при добавлении нового пользователя если такой логин уже есть - то бд будет выбрасывать ошибку.
2. Хотел бы - это понятно, не понятно, зачем?
3. в postgressql есть "уникальные индексы", которые как раз выполняют такую задачу, чтобы в колонке данные были уникальные. К примеру, если у вас есть таблица пользователей, с полями id(генерируется бд), username, то можно создать уникальный индекс на поле username. Тогда при добавлении нового пользователя если такой логин уже есть - то бд будет выбрасывать ошибку.
Похожие вопросы
- Postgresql ввод данных пользователем
- База данных для хранения больших данных?
- Зачем нужны схемы (public) в postgresql?
- Postgresql Как правильно наладить связь между таблицами в базк данныъ?
- как в PostgreSQL(!) сделать группировку по одному полю но вывести в результат остальные поля из таблицы
- Какой тип данных использовать для хранения времени в секундах (php time()) mySQL
- PostgreSQL Extensions. С помощью модуля tablefunc получите из таблицы projects базы HR
- От чего зависит скорость восстановления базы данных?
- Нестандартное извлечение данных из БД
- SQL. Выводятся не все данные. 4 задача.
А что тогда использовать в качестве ссылки на другую таблицу: первичный ключ или натуральный?
По вопросу №3. То есть всё-таки можно "в лоб" добавлять новое значение в таблицу, не проверяя есть оно там или нет, а просто сверять код ошибки?