Евгений Вольф

За последние несколько лет перепробовал очень много различных программ для работы с БД, и могу Вам порекомендовать DBeaver - она поддерживает множество различных БД, работает под Linux, Windows, MacOS. Конечно, программа не лишена своих недостатков, довольно спорных особенностей и даже багов, но работать с (в) ней ней вполне себе можно. Для бесплатной программы она вполне хороша.

Мне кажется Вы либо как-то слишком перемудрили с логикой, либо подошли к вопросу не с той стороны. К тому же, Вы не указали, касательно какой конкретной БД этот вопрос.

Например, в MySQL'е (в данный момент проверят на MariaDB, но думаю оригинальный MySQL работает так же), если нужно ограничить доступы - это можно сделать на уровне пользователей самой БД, причём выставить отдельные ограничения на каждые: Базу -> таблицу -> отдельную колонку.

Если же Вам нужно ещё жестче ограничить данные - я бы рекомендовал добавлять данные о доступах к самим данным непосредственно.

Например, если бы мы использовали PostgreSQL: в таблицу "news", к каждой новости я бы добавлял список пользователей, которые могут читать конкретно эту новость, в отдельную колонку типа "массив" со списком ID пользователей, что бы иметь возможность делать такую выборку на уровне "чистых запросов" или просто воспользовался бы механизмом row level security (пока не приходилось пользоваться таким, но думаю это как раз то, о чём Вы говорите).

А если MySQL: создал бы для каждой такой таблицы создал бы таблицу-спутник в которой были бы прописаны права на каждую отдельную запись, по такому же принципу, как описано выше. Или попробовал бы реализовать аналогичную схему (как описал в варианте для PosgtreSQL), только роль поля-массива выполняло бы JSON-поле (насколько это сработало бы и насколько бы оно работало быстро, если заработало бы - точно сказать не могу, в MySQL я так делать ещё не пробовал, но в теории так сделать можно).

В Вашем варианте мне решительно не нравится то, что Вы храните имена таблиц в другой таблице. Таким образом, эти имена с большей вероятностью невозможно будет использовать внутри SQL-запроса, что в свою очередь создаёт серьёзную специфику при работе с такой БД, которую я бы настоятельно рекомендовал избегать, в частности что бы гарантировать корректность прав между запросами - нужно будет каждый запрос на SELECT оборачивать в транзакцию, как минимум...

P.S. Ещё вот тут описывают некоторую реализацию row level security для MySQL'а.

Как сформировать 1 запрос UPDATE с тысячей значений?

Вот так, и так до 1000 (или сколько Вам будет нужно):

UPDATE table1
	SET val = CASE
		WHEN id = 1 THEN 10
		WHEN id = 2 THEN 20
		WHEN id = 3 THEN 30
	END
  -- тут ещё можно дописать условие, типа WHERE id IN (1,2,3)

По одному запросу посылать не вариант.

По моему, Вы пытаетесь вывернуть бедного дельфина наизнанку через за... Можно посылать много запросов за 1 раз, разделяя их ";" (точкой с запятой). Более того, их так же можно обернуть в транзакцию (как много запросов по одному, так и много запросов через ";").

P.S. Пример таблицы над которой проводились эксперименты: (на всякий случай)

Хочу чтобы вывелся результат, в котором первый столбец - значения table1.items, второй столбец - значения table2.items делаю так:

Попробуйте так:

select table1.items, table2.items from table1 left join table2 on true

Помимо всего прочего, к запросы выше можно применять и group by и всё остальное. Но, если Вы внимательно почитаете про стандарт SQL, то поймете, что данные могут выводиться в совершенно хаотичном порядке (при отсутствии соотв. сортировки) и то, что данный запрос имеет некоторый оттенок маразма, так как данные хоть и выводятся так, как Вы сказали, но куда бы их в таком виде можно было применить, без отсутствия сопоставлений (с учётом того, что я озвучил выше) - придумать довольно таки сложно.

С учётом сущности "квартал" - вряд ли получиться логичней, не припоминаю ни одного готового формата/стандарта даты в БД, где было бы поле "квартал", если только свой составной тип сделать, но такой фунционал "из коробки" в MySQL отсутствует и вряд ли так вот просто получиться в MySQL его "вкрутить".

Единственный вариант, который приходит мне в голову - изобрести свой формат даты на основе поля CHAR/VARCHAR, типа ГОД-КВАРТАЛ-МЕСЯЦ-ДЕНЬ, и пустые значения соотв. заполнять нулями, так по крайней мере будет какой-то намёк на корректную сортировку.

Не совсем понимаю Ваш вопрос, но если Вам нужно, что бы вместо выбранные значения составляли 40% от оригинала, то код (обычный SQL, насколько это применимо к Access я не могу сказать) выглядел бы примерно так:

SELECT (id * 0.4) AS percent from table1
-- или так:
SELECT *, (id * 0.4) AS percent from table1

Где ID - это поле, 40% которого нам нужно получить.

Я точно не помню уже, давно с FB работал... Но, из всех известных мне SQL-БД -- MySQL единственная база, из тех, что изобрели "Свой SQL с блекджеком и... своим форматом LIMIT'а".

Вот, нашел цитату, касательно FireBird 1.5:

Firebird полностью поддерживает SQL-92 Entry Level 1 и реализует большую часть стандарта SQL-99 c некоторыми очень полезными дополнениями. Это включает выражения DML/DDL, синтаксис объединений FULL/LEFT/RIGHT [OUTER] JOIN, выражения UNION, DISTINCT, подзапросы (IN, EXISTS), встроенные функции (AVG, SUM, MIN, MAX, COALESCE, CASE, ..), ограничения целостности (PRIMARY KEY, UNIQUE, FOREIGN KEY), и все общие типы данных SQL.

Следуя выше написанному, и тому, что Postgres так же реализует большую часть этих стандартов, запросы должны работать и в FireBird и в Postgres, практически без изменений. Кроме того, насколько я помню, в FireBird (по крайней мере так было в версиях 1.5 и 2.х) так же как и в Postgres используются "последовательности", вместо MySQL'евского AUTOINCREMENT'а.

Подводя итог, хочу сказать, что Вам нужно искать не то, чем синтаксис FireBird'а отличается от MySQL'евского, а то, чем MySQL'евский-SQL отличается от стандартов SQL.

своеобразный LIMIT

-- LIMIT/OFFSET? Если Вы про него, то это не "своеобразный" LIMIT, это LIMIT в соответствии со стандартами, LIMIT через запятую - это изобретение авторов MySQL'я.

Есть две таблицы. Таблица с этими товарами и таблица с брендами. Эти две таблицы связаны друг с другом через третью таблицу.

У вас один товар может иметь сразу несколько брендов?

Я так понимаю надо сделать таблицу соотношений, где два поля - id_товара и id_его аналога
Допустим у товара с ID 1 есть три аналога - получается на один товар три записи. А у этого аналога в аналогах - товар с ID 1 и оставшиеся два товара. Уже 6 записей. В общем что то мне такое решение не нравится.

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

Если же все товары между собой являются абсолютными аналогами друг-друга, есть альтернативный подход. Он заключается в том, что вы создаёте какую-то группу аналогов, например, в таблице analog_groups, каждая запись в которой = 1 группа аналогов. Далее, Вы указываете в товаре, к какой группе аналогов он принадлежит, это можно делать как по ID группы, так и по её заголовку (или любому другому параметру, который Вы к ней добавите) или по параметру id_группы_аналогов у любого другого товара, который в эту группу уже входит.

Особенности такого подхода:
а) Отсутствие избыточности данных
б) Все товары в одной группе аналогов всегда будут аналогами для всех остальных товаров в этой же группе
в) Нам не нужно будет делать множество одинаковых телодвижений, постоянно перелинковыая аналоги товаров друг у друга
г) Экономиться место на диске и не раздувается БД
д) Мы не можем выставить сортировку или приоритеты вывода аналогов для каждого отдельно товара без жестких костылей