[BadProgrammer]

Jako user id normalnie id czy uuid? #laravel #php #naukaprogramowania #programowanie

[pitu120]

@BadProgrammer: na pewno nie operować polem autoincrement. W jednym projekcie używaliśmy do tego https://github.com/ivanakimov/hashids.php

[BadProgrammer]

@pitu120: czemu nie auto increment?

[sokytsinolop]

@pitu120: to chyba zależy od aplikacji
@BadProgrammer: bo ułatwia scrappowanie danych... np id wpisu na wykopie jest zwiększane o 2 (z powodu jakiegoś buga najprawopodobniej)

[pitu120]

@BadProgrammer: zależy od systemu, jeżeli jest to prosta strona i nie przeszkadza Ci, że ktoś może przeskanować ci profile użytkowników to zrób na auto increment. Samo pole możesz mieć z auto increment ale użytkownikom bym tego nie przekazywał intem tylko użył np. wspomnianego hashids.
@sokytsinolop: właśnie odpisywałem :)

[larvaexotech]

@sokytsinolop: O wiele lepiej jest korzystać z ID auto_increment. Jaką Ty chcesz mieć wydajność np. przy milionie userów w takiej bazie? A jeśli chodzi o scrapowanie danych, nic nie stoi na przeszkodzie, żeby w tabelce userów utworzyć pole typu jakiśtam token czy coś i podgląd profili użytkowników realizować na podstawie tego tokenu - przez analogie, np. przypomnienie hasła też ma swoje ID auto-increment w bazie, ale jak chcesz odzyskać hasło przez

[5z7k9]

@BadProgrammer: https://github.com/hafael/laraflake lub jakakolwiek implementacja Snowflake...

[sokytsinolop]

@larvaexotech: da się indeksować kolumny które nie są inkramentowane

http://kccoder.com/mysql/uuid-vs-int-insert-performance/

ale racja, jest wolniej, ale nie przy milionie userów ;)

[f.....w]

@sokytsinolop: autoincrement nigdy nie oznacza i nie oznaczało że id będą ładnie rosnąc po kolei.

[larvaexotech]

@sokytsinolop: Da się, ale indeksem jest wtedy hash z ciągu znaków, czyli przeszukiwanie jest oparte na btree. Indeksy auto_increment są bardziej zoptymalizowane ze względu na kilka faktów - między innymi fakt, że nowy id jest zawsze wyższy od ostatniego id (nie ma konieczności sortowania indeksów przy insertach), fakt, że ogólny storage kluczy zajmuje mniej (więc siłą rzeczy szybciej się po nich przeszukuje) do nawet takich ogólnych bzdur typu że id które

[sokytsinolop]

@larvaexotech: a jak to jest w mongodb? Zdaje się że tam w objectid jest kilka losowych bajtów, a jednak sprawdza się zarówno w małych jak i dużych bazach

[larvaexotech]

@sokytsinolop: Niestety tutaj nie pomogę, bo nie mam na ten temat wiedzy. Moja przygoda z Mongo się bardzo szybko zaczęła i jeszcze szybciej skończyła ( ͡° ͜ʖ ͡°)

[Benzen]

A jeśli chodzi o scrapowanie danych, nic nie stoi na przeszkodzie, żeby w tabelce userów utworzyć pole typu jakiśtam token czy coś i podgląd profili użytkowników realizować na podstawie tego tokenu

@larvaexotech: @sokytsinolop: Zawsze można po nickach ( ͡° ͜ʖ ͡°) Ogólnie nawet na wykopie zrobione jest to tak, że nie ma nigdzie jawnie pokazanego id usera a pewnie to zwykły auto_increment.

[hostit-pl]

@BadProgrammer: Jeżeli już chcesz przechować dane, gdzie kluczem głównym jest UUID masz dwie możliwości:

1. Przechować UUID jako int nie string
2. Stosować autoincrement zas UUID wykorzystywać jako drugi index

http://kccoder.com/mysql/uuid-vs-int-insert-performance/
https://stackoverflow.com/questions/2365132/uuid-performance-in-mysql

Jest jeszcze trzecia droga, której największym promotorem jest Twitter, tzw. algorytm snowflake id - bardzo fajnie
się sprawdza i mocno go wykorzystujemy

SnowflakeId łaczy dwie ide UUID i autoincrement + w miare zwięzłe przechowywanie danych.

Są jeszcze gdzieś opracowania