Auto_increment придумал дьявол

Возможно здесь имеется ввиду невозможность горизонтального масштабирования для таблиц с колонкой auto_increment.

SQL не торт
auto_increment придумал дьявол

По всей видимости им не нравится слишком умная база с логикой внутри.

Ъ: Разработчик PHP (server-side) (от 90 000 до 120 000 руб., Москва, более 6 лет)
http://hh.ru/vacancy/9031983

Вы уже понимаете что SQL не торт, популярные SQL-сервера еще более не торт, а auto_increment придумал дьявол.

неа мы не понимаем.
обычно такие слова произносят разные сектанты воспитанные деревянными игрушками, прибитыми к потолку и прочим мусором из тяжелого программистского детства. а потом они познали «истину», у таких много тараканов.

Вот десять признаков, чтобы понять подходим ли мы друг другу

как я и говорил сектанты ... и сленг и «признаки» всё от них.

Понимаете, что CGI-модель несовершенна, и 10-15 мегабайт памяти под каждый выполняющийся запрос это слишком

Ненавижу говнопхпшников!

«Сайт компании. http://bitfile.com BITFILE — это проект, помогающий человеку хранить, пользоваться и обмениваться файлами»

«бог убивает котенка, не торт, торт, ароматный бисквит»

«Предупреждаем сразу, придётся думать.»

Вы чего, серьезно хотите на них (или, скорее, на него) работать?

уже 5 человек подписалось на тему :) вероятно, заинтриговало. только еще никто не раскрыл мысль

Вакансия доступна для соискателей с инвалидностью

Мне кажется, это всё объясняет.

SQL - торт?

Молодая активная команда разработчиков, ориентированная на успех.
А ты молодец, не поленился зарегистрироваться ради тиражирования вброса.

SQL - торт?

Торт, конечно.

А вот когда сайт компании ( http://bitfile.com/ ) показывает чистую страницу (похоже, просто запаркован) - бог убивает котенка

И связку MongoDB + PHP придумал дьявол

Торт, конечно.

В новую неделю с хорошим настроением.

В принципе в некоторых случая возможно (коряво конечно) если сместить начальные значения на машинах, а прыгать сразу например на 100. Есть запас до 100 машин

Но да, все же если есть возможность, то лучше использовать какой-то UUID, так как он будет независимо генерироваться на машинах, а если надо, то и на клиентах

Если один сервер СУБД, то побоку

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

А разве обратное требование не является незаконным?

Вот опять эти московские зарплаты... хотя бы половину от такой. :(

а ты знаешь, чем авто_инкремент плох?

Спасибо!

Нет, работу не ищу, стараюсь периодически просматривать требования в вакансиях, хочется соответствовать.

Давно хотел зарегистрироваться здесь, вот появился повод.

и?)

Кто знает - объясните мне, пожалуйста, чем это объясняется?

тяжелой травмой головы, вероятно еще в детстве

Ну первое что в голову приходит - он плохо масштабируется. В смысле, тяжело использовать в распределённых хранилищах. Используем UUID.

Вот опять эти московские зарплаты...

Завидуете? Да ну, пустое это все, суета и тлен. У вас же там, в немоскве, природа, люди душевнее, женщины с приятной наивностью.

А к этому битфайлу придут через пару месяцев инвесторы, спросят: «ну как там твой убийца дропбокса поживает?», да и прекратят финансирование

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

Наивный. Для просветления: У IBM сейчас нехватает программистов на коболе для их мейнфреймов. Ибо не торт.

Судя по их не любви к auto_increment и стилю записи я могу предположить что они используют mysql с репликацией, где auto_increment идет с кучей особенностей, назовем это так.

Но я бы не стал идти работать к этим людям, мозги засрут, переучиваться придеться.

UUID много места занимает

PHP-шники, объясните что не так:

бог убивает котенка, когда пишут for ($i = 0; $i < 10; $i++)

На самом деле хотели сказать, что Бог убивает котёнка на каждые новые 100 строчек кода на php.

foreach же. Ну и да, в целом соглашусь с mashina

Мы NoSQL разработчики. Мы не хотим целостности и персистентности данных, мы хотим 100500 запросов в секунду!

NoSQL не даёт персистентности данных?

NoSQL не даёт персистентности данных?

вроде как изначально это были сугубо in-memory хранилища.

foreach же.

с range()? Оно же реальный список создаёт, если ничего не путаю

Он наверное думает, что так будет круче:

for ($i = 0; $i < 10; ++$i)

А там не получается для каждого инстанса свой range для автоинкремента прописать?

Подсмотрели у плюсовиков небось.

Там простая последовательность, от начала и до забора :)

Я конечно не настоящий сварщик, но была надежда что исходный автор предполагал использование foreach :)

У IBM сейчас нехватает программистов на коболе для их мейнфреймов

Да зачем нам IBM? Еще и кобол, мейнфреймы какие-то.

Вот у нас есть Битфайл Лимитед, у них планируется «проект, помогающий человеку хранить, пользоваться и обмениваться файлами».

И есть аналоги, тот же дропбокс. Они используют MySQL.

Битфайлу конечно виднее кто торт а кто не торт, но дропбокс сделал сервис, а битфайл не может сделать сайт своей компании

Я вообще слабо понимаю, на каких масштабах сочетаются mapreduce и php. Вот фейсбук - хороший пример.

вроде как изначально это были сугубо in-memory хранилища.

memcache штоле :) ?

PHP-шники, объясните что не так:

Думаю, речь об именовании переменных.

Битфайлу конечно виднее кто торт а кто не торт

Ты упорот или просто не читал тред?

Скорее всего имелось в виду использование постфиксного инкремента вместо префиксного. Постфиксный инкремент создаёт временный объект, поэтому он считается более медленным. Правда сишные компиляторы, к примеру, уже давно научились оптимизировать постфиксный инкремент, а за PHP я не скажу, так что не знаю, насколько этот аргумент состоятелен.

А что там с именованием переменных не так? i, j, k, … — устоявшиеся названия для счётчиков цикла.

Очень раздражают шуточки в описаниях вакансий.

Если нет контекста - да, обычно контекст есть, можно написать более читаемо.

наркоманы какие-то