2014-01-28 7 views
0

я получал в вопросе, когда я получил этот сценарий:Лучший способ получить читаемый данные из идентификатора

Я должен сделать историю журнала о том, что пользователь делает и, конечно, пользователь может сделать много другое действие ,

Я думал, что два разных способа, чтобы сделать это, мне просто нужен кто-то, кто может помочь мне правильно следовать.

Первый способ:

2 разные таблицы

  • History_user
  • History_type

History_user стол

id | user_id | history_type (int) 
1  1    1 
1  3    2 

History_type

id | name_action (string) 
1 The user has posted on the wall 
2 The user has change his profile picture 

, а затем просто присоединиться на запрос с History_user.history_type = History_type.id

Второй способ:

это создать таблицу History_user и вспомогательный пример под названием конвертер.

<?php 

class Converter { 

    function history($type_history) { 
     switch($type_history) { 
      case 1: 
      $human_history = "The user has posted on the wall"; 
      break; 

      case 2: 
      $human_history = "The user has change his profile picture"; 
      break; 
     } 

     return $human_history; 
    } 

} 

$converter = new Converter(); 
$converter->history(1); 

Я искал лучший способ сделать это с точки зрения производительности и ремонтопригодности. Спасибо.

+1

Я бы просто сделайте соединение, которое, если проиндексировано, будет очень быстрым. Сохранение данных в таблицах также намного лучше для обслуживания. – Kickstart

ответ

1

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

Вы все еще могли бы сделать эту вспомогательную функцию, которая позволяет сказать, будет иметь статическую переменную кэш - массив ид => имя функции действий, которые будут ленивы загружены на истории(), как это:

class Converter { 
    protected static $_cache; 

    protected static function _loadCache() { 
     if (null !== self::$_cache) { 
      return; 
     } 
     self::$_cache = array(); 
     $query = "SELECT * FROM `History_type`"; 
     $res = mysql_query($query); 
     while ($row = mysql_fetch_assoc($res)) { 
      self::$_cache[(int) $row['id']] = $row['action']; 
     } 
    } 

    public static function history($id) { 
     self::_loadCache(); 
     return isset(self::$_cache[$id]) ? self::$_cache[$id] : 'Undefined action'; 
    } 
} 

Converter::history(1); 
+0

Благодарим вас за ответ, но когда вы сказали «вам понадобится еще один запрос, чтобы получить описания действий (без объединений, ofc, если вам нужна какая-то производительность)». Как получилось, что более высокая производительность делает 2 запроса, а затем 1? Вы можете быть более точными, потому что я не понял, как помощник может быть полезен, имея обе таблицы. Я ценю вашу помощь. :) Приветствия! – Fabrizio

+0

С двумя таблицами вы теряете производительность при попытке представить журнал действий некоторых пользователей. Потеря производительности равна одному запросу с использованием поля индекса, это не слишком большая потеря. При вставке в журнал нет разницы - вы все равно будете вставлять только в одну таблицу. –

+0

Или вы имеете в виду часть «no join»? Соединения не быстрее, чем два запроса. Особенно, когда речь идет о «повторных» смежных значениях. –

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