2016-04-30 2 views
0

Есть ли принятый/безопасный способ игнорировать оператор insert, если таблица или поле в таблице не существует?mysql: Игнорирование INSERT, если таблица и/или поле не существует?

Я трачу много времени, пытаясь отфильтровать массив против «списка исключений» (также массива), и я понял, что если «список исключений» часто изменяется, это может быть головной болью обслуживания. Мне интересно, не будет ли проще обрабатывать весь массив, создать желаемые запросы INSERT/UPDATE, и если данные не требуются (в это время в любом случае), просто игнорируйте запрос INSERT/UPDATE. В будущем, если ранее проигнорированные данные были желательны в будущем, измените базу данных вместо того, чтобы переписать список исключений ... полностью немой идеей?

Разъяснение массив данных мы начинаем с:

Образец массива (который исходит от третьих сторон и может быть изменена) будет выглядеть следующим образом:

{ 
      "ItemTypeCode": 0, 
      "ItemTypeDescription": "Normal", 
      "VendorId": "621eb496-d6d1-4860-af9b-ccae97bf4ef8", 
      "PurchaseOrderId": "d10991e0-a3b5", 
      "FreightDataId": null, 
      "Quantity": 1, 
      "Model": "ZZEAGLEUPGR", 
      "StockModel": "", 
      "AltStockModel": "", 
      "AltModel": "", 
      "CatalogProdId": "723b8e0b", 
      "CustomerSpecificPricings": [], 
      "GasSteamUtilityGrids": [], 
      "HvacUtilityGrids": [] 
     }] 

, где конечный пользователь может не понадобиться (в это время в любом случае) «FreightDataId» или любая из данных в поддиапазоне «GasSteamUtilityGrids».

+0

Да, немой идеей. Я бы использовал некоторую систему контроля версий, например, [tag: git] для PHP-кода и поместите INSERT в ближайшие таблицы в другую ветку. Затем, когда придет время, активируйте эту ветку (= код). – PerlDuck

+0

@PerlDog - не знаю, как git применяется (и, вероятно, это плохо для неясности), но массив приходит ко мне как json и сохраняется в базе данных MySQL. Файлы json являются многомерными, а список «исключить» может быть на разных уровнях json, т. Е. Файлы json не все структурированы так же, как и у разных поставщиков, но одни и те же ключи используются между различными поставщиками. –

+0

А, ОК. Тогда забудьте мой комментарий. Я не так тебя поняла. – PerlDuck

ответ

0

Не поддавайтесь соблазну идти этим путем.

Если вы разрешаете пользователям указывать имена таблиц и столбцы, вы уже находитесь на опасном пути. Я бы настоятельно советовал этому. Защита является первозданной.

Но если это так, как вы хотите продолжить, на самом деле вы не должны использовать черный список (исключить список), а белый список (включить список). Пользователь может указать только перечисленные таблицы и столбцы для выполнения действий с базой данных. Это означает, что когда вы добавляете новые таблицы и/или поля, вы в безопасности, даже если вы забыли адаптировать белый список.

Не пытайтесь обойтись без такого списка. Защита гораздо важнее, чем преимущество отсутствия такого (белого) списка.

+0

У меня нет проблем с сохранением белого списка для db, я просто не уверен, что это происходит, поскольку для фильтрации данных в точке, где обрабатывается массив. У меня нет контроля над массивом (они предоставляются третьей стороной) - поэтому кажется, что если весь массив обрабатывается (используя foreach или аналогичный), то я могу сосредоточиться на том, что на самом деле должно быть в db для конечное применение. Спасибо за комментарий. –

+0

Я вижу. Трудно представить цель этого массива. Если вы хотите получить более глубокое мнение по этому поводу, вы добавите образец содержимого такого массива и укажите, что вы с ним сделаете. – trincot

+0

А, это не работает хорошо в комментариях (когда вы используете теги). Можете ли вы добавить дополнение к своему вопросу и поставить его там? – trincot

Смежные вопросы