2016-08-23 7 views
0

Я работаю над системой продажи билетов в PHP и mySQL. У меня есть таблица support с id как мой первичный ключ и AI.Как создать ссылочный номер билета в PHP и mySQL

Я хочу добавить ticket_number, так что, когда билет отправляется, каждому билету присваивается уникальный номер. Я не могу использовать mySQL для AI в качестве второго поля, не так ли?

Если я дам первый билет номер, затем написать запрос для поиска в БД последний ticket_number, то я думал сделать что-то вроде:

$ticket = 1; 
$next = $ticket+1; 
echo "ticket number: #".$next; 

бы эта работа или есть лучше путь?

+3

При вставке записи в таблицу 'support' вы можете использовать [insert_id] (http://php.net/manual/en/mysqli.insert-id.php) для получения идентификатора AI, который был вставлен. Нет необходимости в этом материале '$ ticket + 1'. – MonkeyZeus

+0

@MonkeyZeus Я могу получить идентификатор строки из запроса (я уже думал об этом), но мне нужно, чтобы мои ответы принадлежали к той же группе. I.e номер билета, а не номер строки. – user3464091

+0

Я не понимаю. Как билет не является уникальной записью в таблице 'support'? – MonkeyZeus

ответ

-1

я решил приспособить ответ @Himanshu Кумар следующим образом (как это решает мой orgional вопрос), чтобы использовать идентификатор пользователя и метку времени (оба из которых я использую уже) как номер билета:

$user_id = 7; //example from session variable 
$cur_date = date('dmyHis'); //timestamp ticket submitted 
$ticket = '#'.$user_id.'-'. $cur_date; 

Это создаст уникальную переменную с идентификатором пользователя и датой и временем. Я использовал секунды, чтобы сделать его более уникальным. Затем я воспользуюсь запросом, чтобы найти все сообщения/билеты с этим билетом.

+0

Добро пожаловать в мир уникальных идентификаторов. Поэтому, если пользователь создает билет в 12:01:43, а другой в 14:32:43 в тот же день, вы получите тот же идентификатор. Да, это будет **. – jcaron

+0

Вот почему я добавляю идентификатор пользователя в метку времени, чтобы создать идентификатор билета ... – user3464091

+0

Также это будет другой номер билета, потому что время РАЗЛИЧНОЕ !!! – user3464091

-1

Вы можете выполнить приведенный ниже код. Он будет генерировать уникальный номер билета каждый раз, когда

$brand = '#ref'; 
$cur_date = date('d').date('m').date('y'); 
$invoice = $brand.$cur_date; 
$customer_id = rand(00000 , 99999); 
$uRefNo = $invoice.'-'.$customer_id; 
echo $uRefNo; 
+0

Хорошо, я вижу, что вы сделали ... комбинируя эту дату со случайным номером. Это может сработать. – user3464091

+3

Не очень хорошая идея создать уникальный идентификатор на основе rand. – Hooli

+0

@Hooli Если вы измените «дату», чтобы включить ** секунды **, она станет более уникальной? – user3464091

0

Для хорошего и уникального идентификатора у вас есть гораздо лучшие решения:

  • Вы можете использовать md5 хэш на основе микропоры (такой же, как uniqid с PHP, но более безопасный)
  • Вы можете использовать дополнительный столбец с unique = true functionnality и запросом, чтобы получить максимум из этого столбца и приращения кода перед новой вставкой
  • Вы можете использовать поддержку ID как уникальная запись, это Perfec можно вставить сначала другое поле, а затем вернуть вставленный идентификатор, чтобы обновить идентификатор вашего билета (если это другой компонент вашей таблицы) или показать его одному для своих пользователей, если вы считаете его своим идентификатором.
+0

Хотя криптографические свойства здесь не важны, ** НЕ ИСПОЛЬЗУЙТЕ MD5 **. ** MD5 не работает **. Возьмите хорошую привычку использовать SHA-256 или лучше. – jcaron

+0

Также см. Комментарий к вопросу. Не увеличивайте клиентскую сторону на основе данных, предоставляемых сервером. Это приведет к состоянию гонки. – jcaron

1

Как вам рекомендовано MonkeyZeus, вам необходимо сделать шаг назад и переосмыслить схему.

Вы хотите иметь несколько строк (ответов), которые связаны друг с другом одним идентификатором (номер билета).

Вы определенно хотите, чтобы этот идентификатор был идентификатором строки в другой таблице.

Таким образом, вы должны иметь две таблицы:

  • один для tickets
  • другой для replies

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

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

У вас могут быть другие таблицы (или это может быть то же самое, что и replies) для других видов действий (статус билета, созданный суб-билет и т. Д.).

tickets будет иметь уникальный идентификатор, который вы можете использовать как номер билета (возможно, с каким-то префиксом, возможно, каким-то образом переформатированным).

replies будет иметь уникальный идентификатор (который будет полезен, если вы хотите прикреплять файлы к ответу или редактировать его), а также идентификатор связанного с ним билета.

Позвольте Mysql создать идентификаторы. Используйте API-интерфейс вашего любимого языка, чтобы получить идентификатор последней вставленной строки.

  • DO NOT приращения идентификаторов на стороне клиента на основе максимального ид, возвращаемый сервером. Состояние гонки вырисовывается.
  • НЕ использовать идентификаторы, которые создаются на стороне клиента и не гарантированно быть уникальным
+0

ОК спасибо. Я посмотрю на это. На данный момент у меня есть простая таблица с id, user_id, user_name, subject, message, timestamp. Я собирался добавить статус и т. Д. Далее ... – user3464091

+0

'user_name', вероятно, не должно быть в этой таблице, а в отдельной таблице' users'. – jcaron

+0

Это, но я хотел бы хранить его здесь также. – user3464091

0

@jcaron Я разработал схему - это будет работать? proposed schema for ticket system database

+1

Почему у вас есть как 'ticket_id', так и' id' в 'ticket'? Сохраните единственный уникальный ключ (первичный ключ). Используете ли вы идентификатор целого числа с автоматическим увеличением (который я бы настоятельно рекомендовал), или ваш собственный идентификатор 'varchar' зависит от вас, но вам определенно не нужны оба. Если вы сохранили оба, 'ticket_id' в' replies' должен ссылаться на первичный ключ 'билеты', а не на вторичное поле (особенно если вы даже не установили ограничение UNIQUE на этом). Вам нужно сделать еще немного чтения по дизайну базы данных ... – jcaron