Здравствуйте, Sinclair, Вы писали:
S>Для начала серверу нужно как-то научиться отличать запрос клиента "сохрани ещё один заказ" от "я не понял, ты вот этот заказ уже сохранил?".
Т.е. если на клиенте "подделать" GUID — отослать повторный запрос с тем же GUID и другими данными, то можно изменить результат уже проведённой операции с интересными финансовыми последствиями?
И каждый день — без права на ошибку...
Re[15]: Ключи в базе - гуиды, 80 символов и прочая чухня
Здравствуйте, B0FEE664, Вы писали:
BFE>Т.е. если на клиенте "подделать" GUID — отослать повторный запрос с тем же GUID и другими данными, то можно изменить результат уже проведённой операции с интересными финансовыми последствиями?
Нет, нельзя. Сервер, построенный по REST канонам, получив повторный запрос с тем же GUID и другими данными, вернёт 409 conflict.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: Ключи в базе - гуиды, 80 символов и прочая чухня
Здравствуйте, Ватакуси, Вы писали:
В>Вообщем, всё больше вижу гуидов в базе в качестве первичных ключей.
Мне тоже такое не нравится. Но иногда это нужно. Например, когда БД локально у разных пользователей (или на разных серверах), а их нужно синхронизировать.
В>Я уже молчу про 80 символов в строке (макс.) и вертикальное форматирование. В>У меня экран на 90% пустой!
Это просто дурь и пережиток прошлого.
А я вот привык к табличному форматированию. Но наши гуйщики его не приняли. Говорят мешает смотреть кто код правил, так как хреновые бэймы не понимают, что менялись только пробелы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Ключи в базе - гуиды, 80 символов и прочая чухня
Здравствуйте, Константин Б., Вы писали:
КБ>Здравствуйте, Anton Batenev, Вы писали:
AB>>И, наконец, третье — диапазон uint64 хоть и велик, но все же конечен и в современных реалиях высоконагруженных информационных систем он кончается совершенно неожиданно и внезапно. Например потому что в условиях "пожара" кто-то решил начать эмулировать генерацию uuid на базе int и появились "дырки" в последовательности, а о последствиях такого решения думать в тот момент было некогда.
КБ>Реально были случаи когда девять квинтилионов не хватило?
Было, но как и в случае выше, возникло из-за дырок, возникших из-за неоптимального алгоритма генерации в специфических случаях (при импорте внешних данных).
Re[4]: Ключи в базе - гуиды, 80 символов и прочая чухня
AB>На всякий случай disclaimer — под int я понимаю типичный autoincrement uint64, потому как uuid (да и любая другая последовательность байт) — это тоже int, просто другой разрядности.
AB>Поскольку возможности апгрейда одного физического юнита конечны (апгрейд начинает стоить несоизмеримых денег, если вообще физически возможен), в какой-то момент ты упираешься в производительность железного юнита на запись и тебе становится нужна возможность разделить запись между множеством физических юнитов. Какое-то время здесь может помочь шардирование, но и его возможности конечны.
вот этот момент поясните пожалуйста.
имеется ввиду, что закончатся айдишники в табле для генерации и надо новый сервер?
Re[5]: Ключи в базе - гуиды, 80 символов и прочая чухня
Здравствуйте, e.thrash, Вы писали:
e> вот этот момент поясните пожалуйста. e> имеется ввиду, что закончатся айдишники в табле для генерации и надо новый сервер?
Закончится CPU/RAM/IO (в любой комбинации) и увеличение пропускной способности при помощи апгрейда одиночного сервера в сравнении с разделением на несколько серверов станет экономически нецелесообразным.
Re[6]: Ключи в базе - гуиды, 80 символов и прочая чухня
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, e.thrash, Вы писали:
e>> вот этот момент поясните пожалуйста. e>> имеется ввиду, что закончатся айдишники в табле для генерации и надо новый сервер?
AB>Закончится CPU/RAM/IO (в любой комбинации) и увеличение пропускной способности при помощи апгрейда одиночного сервера в сравнении с разделением на несколько серверов станет экономически нецелесообразным.
а типа гуид уникальный будет на всю пачку серверов в большой системе, а айди на каждом сервере свой будет?