Отображение имени таблицы и имен полей в URL-адресе запроса

Мне было поручено создать этот компонент Joomla (да, joomla; но это не связано), и профессор сказал Я должен сделать свой код как можно более динамичным (код, который требует меньшего обслуживания) и избегать жесткого кодирования. Подход, который мы изначально задумывали, заключается в том, чтобы взять параметры URL, превратить их в объекты и передать их в запрос.

Допустим, мы хотим прочитать отель с идентификатором № 1 в таблице «гостиницы». Допустим, в таблице есть поля «hotel_id», «hotel_name» и некоторые другие поля.

Теперь, подход, который мы использовали при создании строки запроса sql, состоит в том, чтобы проанализировать запрос url, который выглядел следующим образом:

index.php?task=view&table=hotels&hotel_id=1&param1=something&param2=somethingelse

его в объект PHP, подобный этому (показан в эквиваленте JSON, проще для понимания):

obj = {
  'table':'hotel',
  'conditions':{
        'hotel_id':'1',
        'param1':'something',
        'param2':'somethingelse'
}

и запрос SQL будет примерно таким, где условия зацикливаются и добавляются в строку, где поле и значение предложения WHERE являются ключом и значение объекта (все еще в форме JSON для простоты):

SELECT * FROM obj.table WHERE hotel_id=1 AND param1=something and so on...

Проблема, которая меня беспокоила, заключалась в том, что имя таблицы и имена полей указывались в URL-адресе запроса. Я знаю, что это представляет собой угрозу безопасности, поскольку раскрывает элементы, которые следует видеть только на стороне сервера. Текущее решение, которое я думаю, заключается в присвоении псевдонимов каждой таблице и полю на стороне клиента, но это было бы жестким кодированием, что противоречит его политике. и, кроме того, если бы я сделал это и имел бы тысячу таблиц для псевдонимов, это было бы непрактично.

Какой правильный способ сделать это без:

1. жесткого кодирования
2. сохранить код как динамический и адаптируемый

РЕДАКТИРОВАТЬ:

Что касается произвольных запросов (я забыл включить это), то, что в настоящее время останавливает их в бэкенде, - это функция, которая берет ссылку из жестко запрограммированного объекта (больше похоже на показанный файл конфигурации здесь) и анализирует URL, выбирая параметры или сопоставляя их.

Конфигурация выглядит так:

// 'hotels' here is the table name. instead of parsing the url for a table name
// php will just find the table from this config. if no match, return error.
// reduces risk of arbitrary tables.

'hotels' => array(      

  // fields and their types, used to identify what filter to use

  'structure' => array(  
    'hotel_id'=>'int',
    'name'=>'string',
    'description'=>'string',
    'featured'=>'boolean',
    'published'=>'boolean'
  ),

   //these are the list of 'tasks' and accepted parameters, based on the ones above
   //these are the actual parameter names which i said were the same as field names
   //the ones in 'values' are usually values for inserting and updating
   //the ones in 'conditions' are the ones used in the WHERE part of the query

  'operations' =>array(  
    'add' => array(
      'values' => array('name','description','featured'),
      'conditions' => array()
    ),
    'view' => array(
    'values' => array(),
    'conditions' => array('hotel_id')
    ),
    'edit' => array(
    'values' => array('name','description','featured'),
    'conditions' => array('hotel_id')
    ),
    'remove' => array(
    'values' => array(),
    'conditions' => array('hotel_id')
    )
  )
)

и поэтому из этого списка конфигураций:

• если параметры, отправленные для задачи, не завершены, сервер возвращает ошибка.
• если параметр из URL-адреса удваивается, берется только первое чтение параметра.
• любые другие параметры, отсутствующие в конфигурации, отбрасываются
• , если эта задача не разрешена, она не будет указана для этой таблицы
• , если задачи нет, сервер возвращает ошибку
• , если таблица не там, сервер возвращает ошибку

Я на самом деле скопировал это после того, как увидел компонент в joomla, который использует эту стратегию. Он сокращает модель и контроллер до 4 динамических функций, которые будут CRUD, оставляя только файл конфигурации, который будет единственным файлом, доступным для редактирования позже (это было то, что я имел в виду о динамическом коде, я добавляю таблицы и задачи только в случае необходимости дополнительных таблиц) но я боюсь, что это может создать угрозу безопасности, о которой я, возможно, еще не подозревал.

Есть идеи для альтернативы?