Як зберегти запит SQL в таблицю?

Я зберігаю SQL-запит у таблиці бази даних, таким чином зберігаючи використані критерії, незалежно від того, чи вводиться більше записів до db.

Чи є правильний тип даних і синтаксис для зберігання оператора Query. Я встановив тип даних як VARCHAR (1055) , оскільки я думаю, що цього буде достатньо. Чи існує функція MySQL , яка гарантує правильність збереження тексту з точки зору, котирувань і утримання його в єдиному рядку.

Оновлення: причина для збереження запиту

Ми дозволяємо користувачам системи створювати список контактних даних на основі інших користувачів системи, тому вони створюють запит, використовуючи форму, щоб вибрати всі користувачі з типом роботи виконавця.

Вищевказаний запит потім зберігається в базі даних, так що навіть якщо новий користувач буде додано до виконавчого типу, його контактні дані будуть включені при відправці повідомлень.

Я думаю, що це найкращий спосіб зробити це ... чи є у вас якісь ідеї?

5
Звідки ви його зберігаєте? Безпосередньо з консолі? З PHP? З PhpMyAdmin?
додано Автор Aleks G, джерело
З PHP перевірте оновлену причину запиту
додано Автор surfer190, джерело
З PHP перевірте оновлену причину запиту
додано Автор surfer190, джерело
але простіше зберігати лише запит, якщо немає недоліків у безпеці
додано Автор surfer190, джерело
але простіше зберігати лише запит, якщо немає недоліків у безпеці
додано Автор surfer190, джерело
Запит SQL сам по собі - це рядок, тому varchar мені здається правильним типом даних. Хоча це дуже незвично. Я вважаю, що є кращий спосіб досягти того, що ви намагаєтеся досягти. Також здається, що ви створюєте додаткові потенційні точки ін'єкції SQL у вашій програмі, так що ви хочете переконатися, що заяви правильно очищені.
додано Автор David, джерело
Запит SQL сам по собі - це рядок, тому varchar мені здається правильним типом даних. Хоча це дуже незвично. Я вважаю, що є кращий спосіб досягти того, що ви намагаєтеся досягти. Також здається, що ви створюєте додаткові потенційні точки ін'єкції SQL у вашій програмі, так що ви хочете переконатися, що заяви правильно очищені.
додано Автор David, джерело
Я вважаю, що ваші користувачі самі не створюють запит, але ви генеруєте цей запит на основі варіантів, які вони вибрали з вашої форми? Тоді достатньо зберегти ці параметри - якщо ви зможете побудувати запит від одного разу, ви можете зробити це знову.
додано Автор CBroe, джерело
Можливо, мені занадто пізно відповісти. Перш ніж зберігати його, можна спробувати перетворити його на base64. Таким чином можна мінімізувати потенціал ін'єкції SQL.
додано Автор Tutompita, джерело
Можливо, мені занадто пізно відповісти. Перш ніж зберігати його, можна спробувати перетворити його на base64. Таким чином можна мінімізувати потенціал ін'єкції SQL.
додано Автор Tutompita, джерело

7 Відповіді

VARCHAR(1055) will never be enough. Just use TEXT, MySQL's data type for arbitrary-length text (also called CLOB in other databases).

Більше довідкової інформації:

Тим не менш, я думаю, що ви, напевно, повинні моделювати свій запит так чи інакше на прикладному рівні, замість того, щоб зберігати у вашій базі звичайний текст SQL. При зміні схеми всі ці оператори SQL можуть бути неправильними. Удачи міграції, то!

Іншим недоліком вашого підходу є те, що ви створюєте велику проблему безпеки, якщо користувачам дозволено вводити довільний SQL. Чудовий стажер, контракт якого не був тривалим, може зберігатися

DROP DATABASE my_database.
3
додано
@StephenH: Просто хотів бути впевненим.
додано Автор Lukas Eder, джерело
Ну, я думаю, що захистив від цього, не дозволяючи пряму SQl запис, і я ніколи не опублікувати запит, він зберігається в змінних сесії і генерується системою.
додано Автор surfer190, джерело

VARCHAR(1055) will never be enough. Just use TEXT, MySQL's data type for arbitrary-length text (also called CLOB in other databases).

Більше довідкової інформації:

Тим не менш, я думаю, що ви, напевно, повинні моделювати свій запит так чи інакше на прикладному рівні, замість того, щоб зберігати у вашій базі звичайний текст SQL. При зміні схеми всі ці оператори SQL можуть бути неправильними. Удачи міграції, то!

Іншим недоліком вашого підходу є те, що ви створюєте велику проблему безпеки, якщо користувачам дозволено вводити довільний SQL. Чудовий стажер, контракт якого не був тривалим, може зберігатися

DROP DATABASE my_database.
3
додано
@StephenH: Просто хотів бути впевненим.
додано Автор Lukas Eder, джерело
Ну, я думаю, що захистив від цього, не дозволяючи пряму SQl запис, і я ніколи не опублікувати запит, він зберігається в змінних сесії і генерується системою.
додано Автор surfer190, джерело

Немає правильного типу даних для зберігання запиту.

Але ви можете завжди позбавляти HTML символи за допомогою символів HTMLencode.

Або ви можете використовувати PHP htmlentities() для перетворення символів

1
додано

Немає правильного типу даних для зберігання запиту.

Але ви можете завжди позбавляти HTML символи за допомогою символів HTMLencode.

Або ви можете використовувати PHP htmlentities() для перетворення символів

1
додано

Я вважаю, що це не правильний підхід. Не слід зберігати отриманий запит у вашій базі даних, але замість цього слід зберігати параметри, які призвели до створення створеного sql. У вашій реалізації, коли ви хочете змінити цей запит, вам доведеться проаналізувати ваш збережений SQL, щоб отримати параметри, щоб відобразити форму фільтра користувачеві. Проте якщо ви зберігаєте параметри, ви завжди зможете регенерувати запит, коли це необхідно, і легко відображати поточну форму фільтра.

Якщо ви наполягаєте на тому, щоб зберігати ваш SQL tho, як було зазначено раніше, TEXT є правильним типом поля, оскільки набагато менше шансів відрізати рядок sql при обмеженні розміру поля.

0
додано

Я вважаю, що це не правильний підхід. Не слід зберігати отриманий запит у вашій базі даних, але замість цього слід зберігати параметри, які призвели до створення створеного sql. У вашій реалізації, коли ви хочете змінити цей запит, вам доведеться проаналізувати ваш збережений SQL, щоб отримати параметри, щоб відобразити форму фільтра користувачеві. Проте якщо ви зберігаєте параметри, ви завжди зможете регенерувати запит, коли це необхідно, і легко відображати поточну форму фільтра.

Якщо ви наполягаєте на тому, щоб зберігати ваш SQL tho, як було зазначено раніше, TEXT є правильним типом поля, оскільки набагато менше шансів відрізати рядок sql при обмеженні розміру поля.

0
додано

Якщо вам не потрібно передавати параметри, можна виконати CREATE VIEW . Ви можете просто виконати код з PHP за допомогою MySQLi.

CREATE VIEW myquery AS
SELECT * FROM mytable

Використання:

SELECT * FROM myquery

http://dev.mysql.com/doc/refman/5.0 /en/create-view.html

0
додано