База данни - MySQL 5.0.21
В една таблица постоянно се добавят записи.
Тези записи се обработват от хора - има php интерфейс.
Целта е агента да избере необработен ред, да го обработи и да върне отговора.
Проблемът - има случаи когато 2ма агенти взимат един и същи ред. Рядко ама става. И понеже скрипта записва кой кога какво взима (в друга таблица) се вижда че пичовете успяват да вземат същия ред с точност до секунда.
Правихме врътки - тоест скрипта дръпва реда за обработка и го маркира на следваща команда. Опитахме и update...
Сега планираме преход към InnoDB (от MyISAM).
Това е едния подход - да успеем да направим нещата с транзакции. Чуденката ми е - дали select може да блокира само един ред, така че следващ select да избере следващия ред (а не да чака първата транзакция да приключи).
Другия подход - ще си спретна едно допълнително скриптче което ще си слуша на някой порт, и ще връща наистина последователно каквото му искат. Сигурно ама не е елегантно.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

оплетено ми се вижда твоето описание

какво мислиш за идеята да смениш реда на записване и вземане?

в смисъл първо записва че ред е взет и след това го взема
следващия първо гледа дали реда не е взет и ако е свободен резервира и взема

може да се сложи и код да избегне едновременна резервация на ред

този начин не зависи от базата и е за такива които предпочитат да пишат код

също може да прочетеш

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Редактирано от wiz на 14.12.08 01:30.

заложи на неелегантния според теб метод. не знам какво не му харесваш. можеш да го смениш някой ден, когато му дойде приоритета и то ако изобщо се окаже, че другия метод е по-елегантен (въпрос на вкус).

hell storms, rush over the earth
bestial invasioooooooooooon

Тъпото е че баш това парче го прави един друг колега. Мисля че е опитал подобен подход.
В смисъл - единия процес проверява, другия променя (щото вече е проверил), първия също променя - понеже не е било променено когато е проверявал - кофти.

Не смее да легне на changed rows (след update) щото ползвал persistent connection - и не е много ясно - на него, а на мен ич - какво ще стане.
Май ще си заложа на отделния скрипт - поне такива съм правил доста.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

ми като чета как пишеш оставам с впечатление че ти и твоя колега сте затрупани със задачи, нямате време да огледате картинката като цяло и е добре вашите шефове да почерпят някои да помогне

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Редактирано от wiz на 14.12.08 21:28.

И това сме го мислили. Ама и то не ми харесва като решение.
Бачкаме по наследен код. Шефовете са на поне 10 000 км. И има времена - никакъв зор. Тогава тръгваме да оптимизираме - и изниква някакъв пожар. Ама пожар - за вчера. И след това - като нацвъкаме колкото можем какъв да е код, само и само нещо да стане - пак покой и пак чистене и оптимизации.
Картинката като цяло представлява купчини таблици - голяма част от които не се ползват, ама не смеем да трием щото знае ли човек. Към това добавяш още купчини php за веб, perl за AGI, промени в Астериск.
А бе веселба.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

ми това е начин на работа на много места, рано или късно се стига до там че нищо съществено не може да се добави понеже е голяма плетеница

както казваш има начини да се подредят нещата по добре ама не е лесно и струва пари

иначе не ми се вярва че ще намериш кои знае колко по добро решение от функцията която предлагам

Съдържаниет е скрито
Влезте за да го видите

колко са юзърите, които ще заявяват ред за промяна по него? 5, 20, 100, няколкостотин?

hell storms, rush over the earth
bestial invasioooooooooooon

казано с други думи начина да ти хареса повече е вашите шефове да почерпят(някои като мен) и заедно с вас и тях да се подредят нещата с мисъл за напред

ама цената на такова решение е доста по голяма от текущите разходи които правят сега вашите шефове и сигурно не им се дава толкова, подобно тъпо отношение на парче като че ли е епидемия от глупост по фирмите

а и има много възможности проекта да се провали заради някоя добре звучаща почти безсмислена екстра и да завърши с несериозно оправдание като твоето

И това сме го мислили. Ама и то не ми харесва като решение.

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

2 - 5 най-много от общо може би 20.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

По някога ме чуват - та съм спестил някои "екстри".
Ама все пак са си шефове.
За цената - те си знаят. Аз ще опитам със serialize - и ако стане - добре, ако не стане - със екзекютив - там със сигурност ще стане.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

щом юзърите са малко и __ако__ ти се занимава да слагаш чалъми, и __ако__ имаш primary key от горе-долу прост вид (например autoincrement):

1. сложи таблиза с една колона с тип като тази на primary key от същинската таблица
2. сложи й unique key
3. когато юзъра иска да заяви ред за корекции, select-ваш (N+1) реда и 1 по 1 вкарваш ключа в новата таблица
4. първия, който влезе без duplicate key е бил незаявен и юзъра работи по него
5. като свърши работата, триеш от новата таблица (ако е заложено да трябва да се освободи реда за последваща редакция)

в т.3 числото N е максималното количество едновременно работещи юзъри и (N+1) ти гарантира, че в най-лошия случай последния селектиран запис ще бъде свободен. за 20 юзъра едва ли ще се усети някакво забавяне.

лично на мен повече ми допада да има нещо, което да раздава записи (идеята ти за скрипта), но може за вас да не е подходящо.

hell storms, rush over the earth
bestial invasioooooooooooon

ми начина които предожих също ще стане
не зависи от езика и базата и е опростен -> по-лесно може да се поддържа

кво не хареса в него?

май си поредния които пренебрегва опростените варианти и не разбира че имат съществено предимство в случай като вашия когато сте претрупани от задачи

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Докторе ...

Най-чисто е с InnoDB не заради транзакциите а заради заключването по редове:

SELECT ... FOR UPDATE; и никой не може да пипне този ред докато не го пуснеш.

От друга страна това май не е достатъчно защото тогава следващата сесия ще чака търпеливо и накрая пак ще обработи същия ред втори път т.е. трябва или по някакъв начин да маркираш редовете като вече обработени или направо да ги местиш в друга таблица.

И в двата случая с InnoDB ще си гарантираш по-лесна работа.

Най-елементарния подход е ако можеш "обработката" да я вкараш в един единствен UPDATE

Тогава с WHERE правиш промяната само ако редът не е обработен. Остава въпроса как да върнеш на клиентската част какво си обработил аджеба, но това може да се реши с някаква уникална колонка. UUID() примерно, но пък нея можеш да я използваш и за проверка дали редът подлежи на обработка.

примерно:
ALTER ...

ADD COLUMN processed CHAR(36) NULL,
KEY(processed)

UPDATE x SET ......, processed = UUID() ... WHERE processed IS NULL;


Как ти се струва?

Съдържаниет е скрито
Влезте за да го видите

SELECT ... FOR UPDATE
Това не го знаех - явно не съм чел достатъчно. Е никога не съм ползвал транзакции де - та до някъде е обяснимо.
Имаме поле подобно на предложеното от теб - UUID - та явно комбинацията от двете ще трябва да сработи.
Мерси много.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

Точно защото не мисля че е опростен вариант. Опростен вариант е това което предлага salle, ама той си е майстор.
Шефовете - могат да измислят кой знае какво. А новата таблица си е нова таблица - а аз искам да намаля бройката на таблиците.
Пичовете които теглят реда са 2 групи. Днес има 1 от първата и 2 от втората, утре ще измислят 3 групи или дявол знае какво. И трябва да правим 2, 3 или дявол знае колко допълнителни таблици. И като забърша някоя дето не трябва, или ....

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

ми сигурно от много задачи не забелязваш че това което предлагам е по прост вариант

не са необходими допълнителни таблици

нали вече има таблица в която се записва кои какво прави и може би в нея само трябва да добавиш още 1-2 колони: номер на заявка(или дата/час) и кои е текущия потребител, тези колони е по вероятно да ги има вече

още малко и ще поискаш да го направя безплатно че да те убедя че съм прав

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Редактирано от wiz на 16.12.08 19:17.

1. Смятам че salle е много по напред с MySQL от кой да е друг в този форум. Можеш да погледнеш подписа му.
2. Интуицията ми подсказва да заложа на неговото предложение, още повече че и аз търсех нещо подобно.
В края на краищата - колегата ще реши, щото друг прави PHP интерфейсите. Аз го насочих към тази дискусия и толкоз.
От форумите а и от живота съм разбрал едно - даваш съвет а който иска да го следва.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

Смятам, че се предоверяваш на salle -- той работи по репликацията а не по db-enigine-а.

Това което предлага wiz ("проверява дали реда е записан като зает, ако не е -> записва че е зает и го взема") са пълни глупости ако двете стъпки не се случват в транзакция -- дори предполагам, че в момента е така и има проблеми.

Идеята е, че трябва да сериализирате резервирането на редове. Сериализирате = да го направите да се случва серийно, т.е. ако двама потребители са опитват да резервират ред (без значение дали е един и същ или различни) нека това не се случва едновременно, а да се изчакват. Всякакъм друг достъп до таблицата (справки, UPDATE-и) не ни бъркат и няма да ги trottle-ваме.

Нямаме транзакции заради MyISAM-а, обаче забелязвам че разполагаме LOCK-ове на ресурси, конкретно гледам LOCK TABLES tbl_name.

Значи правим си една dummy таблица за целта и резервиране на ред за редакция става по следния начин:
1. LOCK на dummy
2. Намираме "свободен" за редакция (SELECT @free_id = id ... WHERE ...)
3. Маркираме като резервиран за редакция (UPDATE ... WHERE id = @free_id)
4. Пускаме LOCK на dummy

LOCK-а ни гарантира, че двама потребители няма да се "разминат" между 2-ра и 3-та стъпка. Т.е. user A 2. -> user B 2. -> user B 3. -> user A 3. -> ouch.

Съществува голяма вероятност да не съм разбрал "заданието", но и без друго нямаше какво да правя...

cheers,
</wqw>

Съдържаниет е скрито
Влезте за да го видите

след реда които си прочел wiz ("проверява дали реда е записан като зает, ако не е -> записва че е зает и го взема")

има още един ред в които се проверява за едновременно резервиране

я пак прочети текста които съм писал


- проверява дали реда е записан като зает, ако не е -> записва че е зает и го взема
- след това чака малко и гледа дали е записан като зает повече от един път, ако е така гледа кои е резервирал първи и втория се отказва, тук се хваща ако двама са уцелили по едно и също време еднакъв ред, времето което се чака може да е малко че да не се забелязва от потребителите но да е достатъчно да избегне дублиране
- връща реда или грешка според това дали е първата или следваща резервация на реда


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

и понеже съм в добро настроение ето ти и малко дефиниции да попрочетеш какво значи сериализация


Serialization is the process of taking an object and converting it to a format in which it can be transported across a network or persisted to a storage location.

Term Serialization
Definition Conversion of an object (instance) into a data stream of bytes.


http://www.developer.com/net/csharp/article.php/3110371
http://en.csharp-online.net/Glossary:Definition_-_Serialization

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Редактирано от wiz на 17.12.08 00:56.

ми както вече писах предлагам решение което не зависи нито от базата нито от езика

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

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

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Редактирано от wiz на 17.12.08 00:33.

"Смятам, че се предоверяваш на salle -- той работи по репликацията а не по db-enigine-а. "

Това пък какво беше?

Аз толкова години да си мисля, че знам какво работя а то какво се оказа. Не само, че не съм знаел и съм бил работел нещо съвсем друго ами и имало хора които го знаят по-добре от мен.

Съдържаниет е скрито
Влезте за да го видите

Редактирано от salle на 17.12.08 12:49.

"1. LOCK на dummy "

Излишно е да хабиш цяла таблица при положение, че има функции като

GET_LOCK(), RELEASE_LOCK(), IS_FREE_LOCK()

Освен това какво точно печелиш по този начин в сравнение с единичен UPDATE който гарантира, че ще се промени ред само ако вече не е промемян?

Съдържаниет е скрито
Влезте за да го видите

LIMIT 1 ще ти позволи да променяш само по един ред а с @променлива можеш да вземеш току що редактирания ред.


UPDATE x SET ......,
processed = (@las_processed := UUID()) ...
WHERE processed IS NULL LIMIT 1;

SELECT ... WHERE processed = @last_processed;

Съдържаниет е скрито
Влезте за да го видите

Не ме карай да се смея, твоето "решение" никога няма да полети. Някой трябва много да ми е неприятен, за да го посъветвам да изполва random изчаквания и подобни простотии.

И вземи прочети малко за

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Нищо не печеля и "решението" щеше да е излишно ако MyISAM поддържаше малко по custom транзакции от auto-commit. Просто дори в случая може да се окаже, че не става със single UPDATE и тогава да се върне на мануални LOCK-ове.

Ясно е че супер повърхностно съм погледнал ресурсните LOCK-ове на MySQL и решението с таблица е хак. Най-добре е да има примитив critical section и вероятно това емулират съответните функции. Просто всеки диалект решева проблема сам за себе си, във T-SQL има sp_getapplock/sp_releaseapplock за сериализиране на достъп до ресурси (файлове, други бази) извън lock management-а на db engine-а или на distributed transaction координатора.

А това за отдела за репликация е долна инсинуация от моя страна -- просто обичам да се ебавам с авторитети -- от малък съм така :-)) Nothing personal дето се вика, но нишаните на бирата са ми леко смешни.

cheers,
</wqw>

Съдържаниет е скрито
Влезте за да го видите

от къде го измисли тва "random изчаквания "? сигурно нещо си се избъзкал със себе си и за тва ги мислиш такива

не съм писал такива неща, колко да се чака лесно се мери и може да се умножи за по голяма сигурност

никъв проблем не е да се засече колко време е минало докато се изпълнява кода за резервация, да чакаш 10 или 100 пъти по толкова и след това да провериш дали докато се е изпълнявал някои е пуснал резервация за същия ред и са се дублирали... и втория като види че е пуснал дублираща резервация се отказва

например ако кода за резервация отнема 0,001 сек като чакаш 0,1 сек след това ще може да видиш дали е дублирана резервация и втория да се откаже без това забавяне да се усети

твоето поведение е типично за много, аз го наричам затънал в детайлите и дрънка яко глупости

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Значи викаш лесно мериш милисекунди? Със ANSI SQL? С голяма точност? Оптимист!

Стойността, която ще получиш е по-скоро random, но това е най-малкият ти проблем. Решението ти е мърляшко, абсолютно shake-и и никога няма да можеш да го стабилизираш. Типично случай на "write once, debug forever"!

(Още не съм те почнал тебе -- следват две изречения ad-homenium атака)
Какво ли се занимавам с тебе, поредния architecture astronaut! Ходи ръгай hibernate-а, зарежи SQL-а не е за тебе!

cheers,
</wqw>

Съдържаниет е скрито
Влезте за да го видите

и да дрънкаш/пишеш добре звучащи глупости преписани от някъде тва няма да ти обясни как стоят нещата а трябва да се замислиш малко

всеки разумен ще ти каже че кода със заявки към базата се изпълнява за кратки интервали които може да се променят в тесни граници

като сложиш 100 пъти по голямо изчакване си готов

никои нормален няма да ползва сървър с бд на които се чака прекалено при съвременните възможности на машините

само някои дървен философ като теб може да пусне базата на калкулатор и да има оправдание за глупостите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Виж сега, 100 тона шит, твоите "решения" не вярвам дори да са преписани от някъде, освен от някой наръчник на провалени проекти.

Моето предложение е тривиално -- емулиране на critical section със средствата на RDBMS-то -- не съм "преписвал" (какво и да значи това), а комбинирам техники по малко по-находчив начин.

За сведение, твоите random изчаквания, умножени по random коефициент в интервала 10-100 са пъти по-нескалируеми и 100%-ов bottle-neck на една multi-user система. Явно не си пипал достатъчно, за да се осъзнаеш че в такава среда минорните "забежки" се наказват през пръстите.

>> като чакаш 0,1 сек <<
Значи имаш throughput от само 10 резервации в секунда? При изисквания от пимерно 500? Добро е, спор няма...

>> и втория като види че е пуснал ... <<
А третия? Четвъртия? Тоя race condition ще е пълен цирк да се наблюдава! Сигурен съм, че ще има потребители, които ще резервират мигновено и такива, които няма да могат да се доредят, дори и при най-песимистичен timeout на заявката.

cheers,
</wqw>

Редактирано от wqw на 17.12.08 18:46.

точно вървиш по шаблона които споменах: затънал в детайли, дрънка яко глупости и се прави на велик за да го прикрие, много сте такива и сте ми много смешни

колкото и да скалираш все времето за изпълнение ще е кратко щото само малоумен може да ползва калкулатор за сървър за база данни и да има съществено забавяне

ако толкова те притеснява тва изчакване което за теб е рандом може да пуснеш няква статистика, да премериш в какви граници се променя времето за резервация, да го умножиш по 100 и това да ти е параметър за настроика на системата

това което ти предлагам ще ти го предложи почти всеки разумен които се замисли малко вместо да се рови и да преписва добре звучащи глупости

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

а да и още нещо

тези 0,1 сек ги чака потребителя и реално няма да ги забележи
така че около секунда не е проблем

а за третия и четвъртия ще правят като втория. кода може да се напише така че все едно дали е втори или следващ, щом има първи се отказват всички следващи

просто се замисли малко вместо да се изказваш неподготвен

No pain, no gain

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Неподготвен ли? Аз си решавам проблемите с critical section-и, а ти с random изчаквания...

Но спориш, и с мен и със salle, щото ние сме "в детайлите", а ти си "у бизнаса" явно, целия там си потънал.

cheers,
</wqw>

Съдържаниет е скрито
Влезте за да го видите

тези " critical section-и и random изчаквания" май ги има в някаква лекция

сигурно от там си ги полуразбрал и за тва толкова усърдно ги повтаряш

до колкото си спомням лекцията за random изчаквания това което предлагам няма нищо общо с random изчаквания

не можеш да осмислиш картинката като цяло и се чудиш кви глупости да пишеш

и не намесвай salle в твоите глупости

виждал съм много като теб и сте много смешни

No pain, no gain

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

LIMIT 1 - ползваме го и сега, ама не се бях сетил за ползване на променливи. А ги бях чел

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

така че няма лесно да ме изненадате с твоя колега и твоите шефове
Няма и да опитваме.
Ако нямаше транзакции и нямах възможност да си спретна собствен екзекютив - определено твоето решение щеше да върши най-добре работа.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

но нишаните на бирата са ми леко смешни
Ми смей си се. Радвам се че съм те развеселил.
ПП
От доста години - за мен поне, salle е авторитета за MySQL. И това не е на база само подписа му

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

ми не ми се вярва че с транзакции ще стане по лесно ама не ми се занимава повече да пиша обяснения, достатъчно писах на wqw

какво по точно за теб е "собствен екзекютив "?

No pain, no gain

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Не се засягай ама wqw е прав.

Явно не си се сблъсквал с конкурентна работа с база данни. Реална работа имам предвид. Такава в която ти се сипят хиляди заявки в секунда.

Идеята да разчиташ на изчакване за да решаваш проблеми с конкуретна работа е меко казано абсурдна.

Най-малкото защото самото понятие време (в смисъл на порядък на събитията) не съществува в SQL и диалектите му поради фундаметналните принципи на релационния модел.

Да не говорим, че бъркаш елементарни понятия.

"- проверява дали реда е записан като зает, ако не е -> записва че е зает и го взема "

И как точно ще го направиш това горното като SQL заявки?

"проверява" -> SELECT
"записва" -> UPDATE (INSERT, REPLACE)

Станаха две заявки май.

Единствения начин да изолираш повече от една заявка от това което правят другите сесии е като ти затвориш в транзакция.

START ..
SELECT ..
UPDATE ..
COMMIT

и тук почва истинската веселба.

Две транзакции като горната изпълнявани паралелно ще "виждат" едно и също съдържание в началото т.е. SELECT-ът може да върне едни и същ ред за двете. Съответно двата UPDATE ще опитват да променят същия ред и със евентуално изчакване и двата ще успеят. А задачката е това да се избегне.

Окончателно ме развесели обаче с:

"ако MyISAM поддържаше малко по custom транзакции от auto-commit"

Изглежда си единствения на планетата който не е чувал, че MyISAM не поддържа никакви транзакции. Нищо. Дори A-то от ACID не е вярно за MyISAM в рамките на една единствена заявка.

"Просто дори в случая може да се окаже, че не става със single UPDATE и тогава да се върне на мануални LOCK-ове."

Ми да беше прочел ... bira_more явно разбра каквото му обясних ама то е щото той е от старото поколение което и чете освен да пише.

Съдържаниет е скрито
Влезте за да го видите

Ми сървър който връща ID - собствен протокол, собствени тердове, критична секция. Бях споменал че съм писал доста такива. И ще съм сигурен какво става.
Е аз предпочитам транзакции.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

Е - ключа от бараката е в
select .... for update
Поне така разбрах. Иначе - и ние установихме че select'ите има голяма вероятност да видят едно и също - и да стане същото мазало, каквото е в момента или дори по голямо.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

Чувствам се задължен да измуча, макар и да си "нахранил" wiz.

Auto-commit-а на MyISAM е дълбока моя заблуда. Сега вече "прогледнах" и опасенията ми се сбъднаха на 100% -- по-добре да работя с .txt файлове отколкото с подобна "RDBMS".

bira_more може и да чете, но надали разбира какво точно се случва при твоето предложение. Прекъсни ме ако греша в следващите обяснения, в които ще се опитам да развенчая заблудата, в която ти лично го въведе, че едва ли не със SELECT ... FOR UPDATE ще постигне single row lock върху първия ред подходящ за резервация.

0. Приемам, че InnoDB е относителна стандартна имплементация на RDBMS без да съм запознат с конкретната имплементация.
1. Нека заявката изглежда така SELECT * FROM MyTable WHERE IsReserved = 0 FOR UPDATE
2. Нека в MyTable имаме няколко реда с IsReserved = 1
3. В зависимост от коректността на статистиките на db engine-а + ефективността на алгоритмите за lock escalation, съм готов да се обзаложа че в 95%+ от случаите заявката ще "осъмне" с tab lock.
4. Ако има индекс по IsReserved (нещо безумно като изпълнение, но "решение" което с голяма вероятност wiz би придложил гледайки предиката в WHERE клаузата на заявката) 100% от случаите ще имаме index lock на целия индекс.
5. В зависимост от нивото на изолация на транзакциите db engine-а може да се опита да предотврати "фантоми" и веднага ще сложи tab lock
6. "На око" вероятността само за row lock-ове при подобна заявка е минимална.

Сега виждам това предложение:
UPDATE x SET ......,
processed = (@las_processed := UUID()) ...
WHERE processed IS NULL LIMIT 1;

Питам се, след като на MyISAM му липсва A-то в ACID-а, може ли две сесии да UPDATE-нат един и същ ред едновременно и в резултат това:

SELECT ... WHERE processed = @last_processed;

... да не върне нищо? Склонен съм да предположа, че бирата и Co. ще го докажат в практиката или по-рано ако стрес-тестват. Без транзакции е тегаво, а веселбата с MyISAM е пълна. Бих се хванал за custom lock-овете като удавник за сламка в случая. Добре че понe има work around за емулация на critical section-и.

cheers,
</wqw>

Съдържаниет е скрито
Влезте за да го видите

"едва ли не със SELECT ... FOR UPDATE ще постигне single row lock върху първия ред подходящ за резервация. "

При ENGINE=InnoDB

SELECT ... WHERE ... LIMIT 1 FOR UPDATE;

ще постави row lock върху първия намерен ред отговарящ на WHERE клаузата.

"1. Нека заявката изглежда така SELECT * FROM MyTable WHERE IsReserved = 0 FOR UPDATE
2. Нека в MyTable имаме няколко реда с IsReserved = 1
3. В зависимост от коректността на статистиките на db engine-а + ефективността на алгоритмите за lock escalation, съм готов да се обзаложа че в 95%+ от случаите заявката ще "осъмне" с tab lock. "



SELECT * FROM MyTable WHERE IsReserved = 0 FOR UPDATE;

ще осъмне с eXclusive row lock върху всички редове с
IsReserved = 0 в 100% от случаите дори и когато това са всички редове в таблицата.

SELECT * FROM MyTable WHERE IsReserved = 0 LIMIT 1 FOR UPDATE;

ще осъмне с X row lock върху един ред (първия намерен) в 100% от случаите.

Шансът при SELECT ... FOR UPDATE InnoDB да постави Tabel lock е нулев. Мога и да обясня защо ако трябва.

"4. Ако има индекс по IsReserved (нещо безумно като изпълнение, но "решение" което с голяма вероятност wiz би придложил гледайки предиката в WHERE клаузата на заявката) 100% от случаите ще имаме index lock на целия индекс."

Не знам какво точно имаш предвид под index lock в случая. InnoDB използва clustered index където държи Primary Key и точно това е което заключва. Няма вариант да заключи целия индекс обаче освен разбира се когато трябва да заключи всички елементи.

"5. В зависимост от нивото на изолация на транзакциите db engine-а може да се опита да предотврати "фантоми" и веднага ще сложи tab lock "

InnoDB предотвратява фантомите в почти всички случаи дори на ниво REPEATABLE READ, но това всъщност няма значение в случая.

"Питам се, след като на MyISAM му липсва A-то в ACID-а, може ли две сесии да UPDATE-нат един и същ ред едновременно и в резултат това: "

Не.

Въпросът кога точно на MyISAM му липсва A-то e с леко повишена трудност :) Не много, но да речем 6 по десетобална скала ;)

UPDATE x SET ......,
processed = UUID() ...
WHERE processed IS NULL LIMIT 1;

върши идеална работа при MyISAM точно защото при MyISAM няма транзакции и поради това гарантира невъзможност две сесии да променят един и същ ред.

MyISAM поддържа заключване само на ниво таблица.

Съдържаниет е скрито
Влезте за да го видите

Редактирано от salle на 18.12.08 03:20.

"Само не съм сигурен какво се случва ако PHP ползва persistent connection. "

persistent connection към MySQL носят само главоболия. Не случайно в mysqli ги махнаха въобще.

Съдържаниет е скрито
Влезте за да го видите

"Е - ключа от бараката е в
select .... for update "

Не съвсем. select .... for update ти дава възможност да заключваш отделни редове, което е за предпочитане при много паралелни сесии пред заключване на цяла таблица.

Това все още не ти решава проблема, че две сесии могат да променят един и същ ред последователно. Първо едната после другата.

Съдържаниет е скрито
Влезте за да го видите

ми тва което предлагам е близо до твоя "собствен екзекютив" само че реализиран по лесно и с каквото имаш под ръка
иначе по някое време може да стигнеш до там да поискаш да напишеш твои Linux вместо да ползваш готови неща

като гледам със salle сте тръгнали към нещо от което няма полза, не би трябвало да ползвате UUID() и LIMIT щото таблицата трябва да има primary key а с него се взема само 1 ред и е ясно че тои се обработва

транзакциите също не са добър избор " защото тогава следващата сесия ще чака търпеливо "

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

>> SELECT * FROM MyTable WHERE IsReserved = 0 LIMIT 1 FOR UPDATE;

ще осъмне с X row lock върху един ред (първия намерен) в 100% от случаите. <<

Ето това е най-подвеждащото изказване. Значи ако има редове с IsReserved != 0 те няма да се заключат така ли? При положение че самия SELECT ги "пипа"? Говорим за InnoDB.

Относно REPEATABLE READ, с подобна WHERE клауза няма друг начин да ги предотврати освен tab lock, за разлика от READ COMMITED където би трябвало да сложи множество row lock-ове..

Index lock е нещо което ефективно предотвратява фантоми -- просто не позволява да се модифицира (insert/delete) съответния индекс.

Защо трябва да са множество row lock-ове? Неко сложим ORDER BY за да ни е детерминистичен резултата от заявката: SELECT * FROM MyTable WHERE IsReserved = 0 ORDER BY id LIMIT 1 FOR UPDATE;

Ако сесия А установи, че id=1 е резервирано и "заключи" id=2, междувременно сeсия Z освободи id=1, то сесия B ще може да намери id=1 преди сесия A да commit-не. Което може да е търсено поведение в случая, знам ли.

cheers,
</wqw>

Съдържаниет е скрито
Влезте за да го видите

въобще за MyISAM не съм писал, нещо се бъркаш

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

въобще и ти, и wqw и bira_more ми се виждате заровени в детайли и заради това пропускате картиката като цяло, тва като че ли е масова болест

ясно е че може да се претовари някои компютър и 1-2 най прости заявки да отнемат седмици или години ама тва е изключение а не масов начин на работа

ще се съгласиш ли че в масовия случай заявките се изпълняват за милисекунди? включително и на този които ползваме в момента - clubs.dir.bg

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

ми до колкото разбрах от обясненията на бирата тва е сценария които се търси:

около 20 агенти имат списъци с редове от таблица и избират някои ред за редактиране
задачата е да се предотврати случая в които двама избират едновременно един и същ ред, редактират го и го записват

тоест има primary key при потребител, с този primary key се взема реда които е избран(select ... where id=pk), редактира се и се записва обратно в базата (update ... where id=pk)

и моето предложение е да ползва таблицата в която записват вече кои какво прави като се записва че някои ред е зает и втория като види че е зает не пипа този ред, разчитам на това че обикновенно заявките се изпълняват за милисекунди и с по голямо изчакване проверява дали не се дублира резервация

обаче като гледам кво пише бирата почвам да се съмнявам че таблицата има primary key
което значи че базата е несериозна и трябва да се добави на таблицата primary key ...

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Страшна логика извади

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

>> SELECT * FROM MyTable WHERE IsReserved = 0 LIMIT 1 FOR UPDATE;

ще осъмне с X row lock върху един ред (първия намерен) в 100% от случаите. <<

" Ето това е най-подвеждащото изказване. Значи ако има редове с IsReserved != 0 те няма да се заключат така ли? При положение че самия SELECT ги "пипа"? Говорим за InnoDB. "


Ами пробвай като не вярваш

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

"въобще за MyISAM не съм писал, нещо се бъркаш "

Мдам .. така е .. съжалявам.

Нещо ви бъркам с тези подобни прякори wqw и wiz ... а и като стил на писане донякъде

Съдържаниет е скрито
Влезте за да го видите

обърка ме с wqw, сега пък ме разсмиваш с друго

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Редактирано от wiz на 18.12.08 13:53.

ха Явно си пропуснал урока, че и в най-простия софтуер трябва да се отчитат въцможно на-лошите сценарии.

по скоро на теб и на wqw някои повърхностен преподавател със смешна заплата ви е напълнил главите с евтини теории които опитвате да ми ги пробутате ама пред мен не минават

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

ако заявките почнат да се изпълняват за по дълго от 0,05 секунда например значи компа е претоварен и може да се връщат потребители а не да се правят опити да им се прави резервация

лесно може да се сложи код да мери за колко се прави заявка и ако е над опредлено време да прати съобщение че в момента е претоварена системата

например може да се мери за колко се изпълнява селект заявката която показва слисъка с редове от които се избира или update която записва резервацията, ако е прекалено голямо това число показва съощение че има претоварване

а ти някои ден може да съжаляваш че не живееш бункер ама сигурно много повече ще съжаляваш ако всеки ден си в бункер

ето предложение за теб

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Редактирано от wiz на 18.12.08 14:52.

Боже, колко си наивен! По-скоро това е което ние преподаваме на заблудени овце като тебе -- реални use-case-ове от практиката, подковани със стабилна теория преди това.

Съдържаниет е скрито
Влезте за да го видите

А ми не е така. Ако е мой екзекютив - няма да има допълнителни таблици, нито повторни проверки, нито изчакване, нито потенциални серийни колизии.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

Е то ако е да се гръмнеш в крака - начини много.
Ама ние и сега имаме рядко колизии, и смятам че ще се справим.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

очевидно за теб "реални use-case-ове от практиката, подковани със стабилна теория" се нарича повърхностното ти разбиране за "critical section-и и random изчаквания" и други подобни

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

Съдържаниет е скрито
Влезте за да го видите

Редактирано от wiz на 18.12.08 17:23.

ми това което предлагам няма допълнителни таблици, нито забележимо изчакване нито потенциални серийни колизии

а повторните проверки не бих ги нарекъл така

ако почетеш малко wikipedia или няква друга теория може да намериш по добре звучащи термини ако тва те радва

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Повърхностният преподавател в моя случай е практиката

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

"лесно може да се сложи код да мери за колко се прави заявка и ако е над опредлено време да прати съобщение че в момента е претоварена системата "

.. и понеже въпросната заявка се оказва кеширана системата ти винаги да си мисли, че натоварването е малко

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

както сам писа и ти не виждаш стабилно решение

и да е кеширана заявката тва не значи че не се изпълнява, пак сигурно при претоварване ще се забележи че има забавяне което да се познае като проблем

ако не по това все някои друг начин има да се следи за претоварване и за забавяне извън нормалното

като имаш толкова опит да беше следил статиите и основните идеи в тях че да разбереш че масовия предпочитан начин на работа е да не се забелязва забавяния, тоест може да се разчита на това че заявките се изпълняват бързо

твото отношение ми прилича на израза blinded by science
или опитваш да ме затрупаш с детаили като се надяваш да се оплета и да ми пробуташ твоето мнение

споко и на хора с повече опит от теб съм се смял така че не се притеснявай

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

по онова време изчакването наистина не би било добра идея

но както писах при съвременните възможности на машините може да се разчита че заявките се изпълняват бързо за милисекунди

а не някои да си пусне задачата на калкулатор и да се чуди що не стават нещата

такива като теб сигурно им е малко да са в бункер
сигурно искаш да си в някоя пещера на 100 м под земята
ми разбирам те ама повечето предпочитат да са на чист въздух и сред зеленина

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

А защо въобще трябва да връщаш съобщение, че е претоварена системата когато може да оставиш сървъра да си подреди заявката на опашка и да изчака колкото трябва. Нали според теб чакането няма как да е голямо?
защото има реални потрбители които разлеждат редовете, избират от тях някои, редактират го и го записват обратно

безсмислено е да се оставят да чакат, много по лесно и по евтино е да имат бърза машина

на теб май проблема ти е че ти е остарял начина на мислене

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

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

Спирам да храня форумния трол.

cheers,
</wqw>

Съдържаниет е скрито
Влезте за да го видите

ми и написано като код сигурно пак ще си намериш някво несериозно оправдание че да не си напънеш ума да го разбереш

освен това като код може да има повече подробности които да те бъркат, текста които съм писал е по изчистен от не толкова важни подробности

не се прави ами вземи прочети 10-20 пъти това което съм ти писал и може тогава да го разбереш

а и не ми се занимава да го правя безплатно, аз не се казвам дядо коледа ако забелязваш и не раздавам подараци

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

а да и още нещо

пиша тук щото си смешен и щото имам добро сърце

ама тва не значи че ще ти преподавам безплатно уроци или ще пиша безплатно код

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Кажи колко пари искаш, за да направиш примерна постановка?

Съдържаниет е скрито
Влезте за да го видите

ми да се прави цяла постановка за тестване, наблюдение и покриване на всички възможни проблеми може да излезе задача която отнема доста време

по добре дай да видим колко биха предложили шефовете на бирата за research&development

или шефовете на salle от mysql/sun

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Редактирано от wiz на 18.12.08 19:59.

Аз понеже съм проЗ лекар (по образование) ще избера това което съм избрал и толкоз.
Мерси за препоръките.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

А ми така като гледам, си overqualified и за моите шефове, и за шефовете на salle.
Доста усилия положих за да мога да работя с хора с които се разбирам. Трябва да съм пълен олигофрен, за да разваля това което съм постигнал.
Някой ден ще разбереш, може би, че когато някоя твоя идея не се възприема, или приемаш това което се възприема, или намираш място където възприемат твоите идеи. Е това са само клубове.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

хахаха от къде го измисли този филм в които ме сложи?
само ви показвам как стоят нещата щото е забавно
тва май е някъв шаблон на които някой те научил и сигурно сега пробваш да го приложиш за мен
май ме бъркаш с някои, как ги измисли тези:

А ми така като гледам, си overqualified и за моите шефове, и за шефовете на salle.
Доста усилия положих за да мога да работя с хора с които се разбирам. Трябва да съм пълен олигофрен, за да разваля това което съм постигнал.
Някой ден ще разбереш, може би, че когато някоя твоя идея не се възприема, или приемаш това което се възприема, или намираш място където възприемат твоите идеи. Е това са само клубове.

No pain, no gain

Съдържаниет е скрито
Влезте за да го видите

а да и разбира се че сте свободни да избирате и да правите каквото решите

както вече писах няма лесно да ме изненадате

само показвам как стоят нещата понеже имам добро сърце

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Ти сам си се сложи в този филм:
по добре дай да видим колко биха предложили шефовете на бирата за research&development
или шефовете на salle от mysql/sun
Това са твои думи. И аз ти обеснявам че явно си overqualified и за моите и за шефовете на salle.
Или казано с други думи - моите шефове няма да ти направят предложение за research & development.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

как стоят нещата.
Можеш да покажеш как стоят нещата според теб. Но не и как стоят нещата в действителност.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

ми обяснявах на wqw че не ми се занимава току така да му обяснявам нещата

за твоите шефове може да съм overqualified щото вероятно са малка фирма

ама няма начин да съм overqualified за шефовете на salle щото имат доста ресурси в mysql/sun, нещо се бъркаш за това както бъркаш и за другите неща които писа за базата данни

No pain, no gain

Съдържаниет е скрито
Влезте за да го видите

и що така реши че не може да покажа как стоят нещата а само съм можел да покажа как стоят нещата според мен?

тва че вас с wqw ви мързи да прочете 10-20 пъти какво съм писал и да го разберете а вместо тва предпочитате да се правите на много важни аз не съм ви виновен, не ми е работа да ви давам безплатни уроци и да ви обяснявам безплатно и подробно как стоят нещата, такива неща като безплатен обед няма, още малко ще кажеш че съм виновен че не съм ти решил задачата безплатно, я не ме разсмивай с такива

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Overqualified си ама не го разбираш.
Останалите вероятно ще ме разберат по добре.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

И да искаш да я решиш безплатно - пак няма да стане.
Гарантирам ти.
Когато разбереш защо си overqualified, ще разбереш и защо не може да стане.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

май пак пропускаш нещо

ако имаш пред вид този смисъл
http://en.wikipedia.org/wiki/Overqualified
Being overqualified means one is skilled or educated beyond what is necessary for a job

за да се свърши определена ясна единична задача не може да си Overqualified щото може да се свърши по добре и по бързо както е твоя случай
и съотвено за по бързо и по качествено изпълнение се плаща повече

иначе има други задачи за които може да се ползва Overqualified: например когато се очаква някои да стои на постоянна фиксирана заплата за определено време

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

ми добре обясни що според теб съм Overqualified?

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

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Значи - аз не съм шеф. Аз не определям ничия заплата. Единственото което мога да направя е ако шефовете ми поискат човек с определени качества, а аз мога да намеря такъв - да им го предложа. Останалото е SEP - somebody else problem. Включително и договарянето на заплащането.
Та аз не съм шеф и неопределям ничия заплата.
И гарантирам ти не се опитвам да те сложа на никаква заплата.
За overqualified - трябва сам да го разбереш. Аз няма да мога да ти го обясня. Не съм достатъчно квалифициран.

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

хайде хайде не увъртай

вероятно тва е случая: начина ви на мислене на теб и твоите шефове е приравнен към определена месечна заплата и за тва ти се виждам Overqualified

не е добра идея да работя с вас на такава заплата

вместо да признаеш че тва е случая се пробваш да се правиш на важен (заедно с тях ) с което ставате само по смешни

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Бира, абе ти с радиото ли си решил да спориш. Зарежи това пишлеме, не виждаш ли как почна да овърта като плъх на тясно. Момчето явно е много комплексирано от ниската си заплата и все към финанси го избива.

Не храни трола, че скоро ще ни таксува за "знанието", което изля до момента :-))

cheers,
</wqw>

Съдържаниет е скрито
Влезте за да го видите

я ни са прави ми вземи да прочетеш 10-20 пъти кво съм писал
може да си помагате с бирата и с общи усилия може да го разберете, може да включите и сале да ви помага дано заедно успеете да се справите и да го разберете

тва твоето май е шаблона на братята хамериканци - дето си мислят че ако една куха лейка се прави на велика от това ще стане по малко куха

ама както виждаш доиде световната криза и ги слага на място

или твоите номера са като надувките на Буш преди няколко седмици когато предстоеше срещата на Г20 - щеше да охлажда емоциите а след срещата си призна че не очаквал колко прдуктивна ще стане

казано с няколко думи: сядай и чети вместо да пишеш глупости, щото може да се скъсам от смях

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Редактирано от wiz на 19.12.08 12:34.

Ще се опитам да ти го обясня още веднъж. Разбирам че имаш пробжлем с разбирането, ама аз ще опитам.
Значи аз съм freelancer. Бачкам по проекти. Не съм на заплтата.
Писал съм много преди тази тема в различни клубове че съм freelancer. В някои съм търсел и хора със специфични знания и умения. И съм ги насочвал да се договарят.
Заплащането разбира се е ниско. Според американските стандарти, иначе за какво да наемат freelancer'и?
До колкото с теб няма да работим, няма и смисъл да обсъждаме какво заплащане би могъл да договориш и условия.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

По някога обичам да си губя времето с безмислени спорове. Най малкото мога да убедя доста хора че мога да съм много тъп и много упорит.

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

ми както ти писах тва дали ще работя с теб или не не ми е проблем

може да се радваш на другите идеи и да си ползваш уменията за тях(" мога да съм много тъп и много упорит")

ако забеляза и буш преди срещата на г20 се държеше така; мислеше ще охлади емоциите и няма да има съществени резултати, а след срещата си призна че не очаквал толкова продуктивна среща и че ако не вземе мерки го чака депресия по голяма от голямата депресия

та имайки светлия пример на буш няма лесно да ме изненадаш
може да се залъгваш с каквито глупости решиш, включително например вместо таблицата да има primary key да пробваш да го заместиш с някое временно решение както ти пише сале

ама ще е добре ти и твоите шефове да се приготвите за случка като случката с буш

щото с такова смешно отношение рано или късно тва ви чака

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

ми както ти писах тва дали ще работя с теб или не не ми е проблем
Радвам се за теб.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

радвам се че ме разбра най после
по добре щеше да е ако го беше разбрал още с първото съобщение с което опитах да обясня

сигурно wqw завижда на глупостите на буш и опитва да го настигне
май и сале иска да участва в такъв консурс

вероятно за тва се отнасят така, понеже имам добре сърце и ги разбирам им пожелавам успех, да правят още много яки глупости, само да внимават като доиде време за плащане да не се окажат в положение по тежко от голямата депресия

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

явно си много велик. Защо още бачкаш за други, вместо други да бачкат за теб?
И като съм почнал да се чудя - що не вземеш да направиш една истинска база данни, и да пратиш в миналото и MySQL и MSSQL и Oracle и всички останали?
Ще си сложиш изчаквателчета, ще си чакат и никакви колизии никъде.
Знаеш ги нещата - правиш си екип, даваш им акъл какво да правят и готово.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

ми не мисля че съм велик а че съм среден разумен

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

а за изчакването не е проблем да се реализира ако се настрои по скороста на изпълнение на конкретната машина, ако следи и при претоварване отказва

тоест ако се пипне както всяка друга задачка и се нагласи както трябва а не да се търсят добре звучащи несериозни оправдания

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Несериозни оправдания? Като това ли:

>> иначе за да работят за мен ми трябват връзки като на бил геитс да получа поръчки и с парите от тях да си направя монопол <<

Да, всички които правим екипи или работим с клиенти сме с връзки. А ти си най-голямата жертва на света, онеправдан и неразбран. Ох, само да имаше някой да иска да ти чете мъдростите по 20-30 пъти, колко различно щеше да е всичко, какъв пропуск за човечеството!

Дай да те нахраним за утре да ти гледаме цирка :-))

Съдържаниет е скрито
Влезте за да го видите

това което ме храни е тва че темата ми е смешна най вече твоите повърхностни коментари, ама тва е извън твоя контрол

разбира се може да пробваш техниката на глупака: да мълчиш за да не се разбира какво мислиш

не измествай темата, не съм писал такива неща "всички които правим екипи или работим с клиенти сме с връзки. А ти си най-голямата жертва на света, онеправдан и неразбран"

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

а да и да направиш екип пак е като да работиш за някои

разликата е само че има няколко които си назначил да ти помагат

така че тва което писахте с бирата е поредната глупост

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Редактирано от wiz на 19.12.08 17:45.

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

може по някое време и да успеете да настигнете буш

ама мен не ме замесвай не ми е интересно просто да се занимавам с глупости

накрая само може да представите описание на вашите глупости че да ви се смея на един път а не както тук малко по малко

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Редактирано от wiz на 19.12.08 18:01.

Е ние може някой ден да настигнем Буш, ама ти определено го задмина.

Ама все още нечаткаш какво точно означава overqualified в твоя конкретен случай.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

Най се кефя на самочувствието ти. Убеден си че знаеш за MySQL повече от хора които имат и сертификати и работят за MySQL.
Това го възприеми като hint за overqualified в твоя случай.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

ми чаткам и съм виждал много неща...както вече ти писах не е лесно да ме изненадате, има 1-2 вероятни смисъла ама да беше го написал вместо да увърташ

сигурно ви се иска да съм виновен че си държите на глупостите и се подрепяте в тях и че трябва да ви обяснявам много внимателно да не би да ви засегна случайно? сигурно и буш ги пробвал всевъзможни такива номера преди срещата на г20

обяснявам как стоят нещата и няма как да съм написал такива големи глупости като тези на wqw например, единствено може да съм засегнал някои от участниците ама тва е нищо с сравнение с това което чака такива с такова смехотворно отношение като вас дето вместо да видят как стоят нещата пробват да се подкрепят в глупостите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

оф ми пак замеси MySQL

аз ти казах че предлагам решение което не зависи от базата и езика

самочувствието ми няма нищо общо в случая, показвам ти реални факти от които ще имаш полза и те нямат общо с това какво ми е самочувствието

фактите също не зависят от това дали имам сертификати или от това за кои работя

все едно да кажеш че имаш голямо самочувстие че се осмеляваш да се огледаш

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

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

нали не е нужно да знаеш всички детайли за пода за да можеш да ходиш?

нали като цяло не може да се каже:
- че майстора на паркет понеже знае повече за него може да ходи по бързо?
- или че пътния инженер които прави асфалта може да тича най бързо по улиците?

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

>> а да и да направиш екип пак е като да работиш за някои <<

Разбира се, че винаги работиш за някой. Леката разлика е че на мен "шефове" са ми моите клиенти. Не е като да си лежа на една кълка и по цял ден да псувам началниците по форумите.

Като разбеснял се трол си обаче и истински се забавлявам да те ръчкам и да ти гледам сеира :-))

Съдържаниет е скрито
Влезте за да го видите

хаха нито съм "разбеснял се трол "
нито можеш да ме ръчкаш
нито може да ми гледаш сеира

дали работиш за шеф или за клиент е все едно когато имате добри отношения и се разбирате, съответно и работното време може да се избира както е удобно за всички, и работата е същата, тва ти е поредната глупост

разлика може да има само когато някои шеф се прави на велик и си търси роби да ги експлоатира като не се сеща че е тръгнал по пътя на руския цар...което е тъп сценарии ама като гледам твоето поведение ти подхожда

единственото което можеш е да ме разсмиваш с повърхностни коментари и повърхностни опити да извъртиш нещата

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Напротив - твоето решение, е едно от първите които хрумва в главите на хората, и се отхвърля също толкова бързо колкото е хрумнало.*
Това че ти хрумна е добре, лошо е че не може да разбереш защо е крайно неудачно.
Аз ползвам MySQL. За това изрично съм написал какво конкретно ползвам. Ако ползвах какво да е, което не поддържа транзакции, аз нямам достъп до сървъра, и не мога да добавям таблици - е твоето решение остава май единствено. Но аз ползвам версия на MySQL която има транзакции, аз имам достъп до сървъра, и мога да правя таблици. Така че твоето решение не е подходящо. Защото има по подходящи. Изчакването не е опция. Няма да се опитвам да ти обяснявам защо, ама не е опция.
_________
*Е на мен не ми хрумна, ама на един колега му хрумна - преди да питам във форума.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

Ако не си виждал бази данни и никога не си работил с бази данни - може да предлагаш изчакване. Колегата който го предложи (както споменах в предното си мнение) не е работил много с бази данни за разлика от мен и особено третия колега, който конкретно гони проблема.
Защо не трябва да се ползва е нещо което явно няма да можеш да го разбереш.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

ми виждал съм и съм правил доста неща с бази данни ако тва ще те накара да се чувстваш по добре

май най добрия вариант е комбинация от това което предлагам със заключване - например заключва се таблицата за малко докато се резервира реда и това ти гарантира че няма да се дублира резервация , та май излиза че транзакциите може да си ги спестиш и по друг начин без изчакване

така се избягва изчакването което предлагам и което не ви се вярва че може да се ползва

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

що сале не препоръча да се сложи primary key на таблицата а прави опит да го замести с временно решение когато има mainstream подход - да се ползва primary key?

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Редактирано от wiz на 19.12.08 20:54.

Ако имам транзакции няма да има нужда от изчакване.
А транзакциите ще решат и още няколко проблема, които все още не са възникнали, но ще възникнат.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

ок ми не ми се занимава с безкрайни спорове както му се иска на wqw

не ми се и занимава да разглеждам подробно твоя случай (щото не работя безплатно)

само мога да кажа какво ми е впечатлението до тук:че имаш повърхностно решение което е доста вероятно да подобряваш в бъдеще, когато се решите да го реализирате или когато се появят първите проблеми

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Моя случай не можеш да го разглеждаш подробно.
Просто както вече установихме не е подходящ за теб.
Защото си overqualified.
А на мен ми е омръзнало да се занимавам да обеснявам елементарни неща на overqualified хора, поради което направих каквото трябва и зависи от мен да не ми се налага да обеснявам елементарни неща на overqualified.
Освен едно изключение разбира се - по форумите.

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

нали 100 пъти го спомена тва overqualified
а само един път опита да го обясниш и то неясно

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

които е далече от реалноста на моя опит и умения, ама тъй като не ме познаваш ти е по лесно така

иначе за мен форумте са предимно забавление, излизат много смешни неща като например изявленията на wqw

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Тва за филма мисля че го изяснихме. Ти се вкара сам в него.
Твоите опит и квалификация се разбрахме че не са подходящи за случая. Подробностите са без значение.
Иначе - благодарности за това че се опита да бъдеш полезен.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

ми точно подробностите са интересни

как реши че съм се вкарал във филм
и що увърташ вместо да напишеш направо какво мислиш?

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Подробностите са интересни само за да се вихри спор. Но не са важни, защото в крайна сметка независимо от тях резултата ще бъде същия. А именно - всеки ще си работи по неговите си неща, по неговия си начин.
как реши че съм се вкарал във филм
Вкара се във филма със:
по добре дай да видим колко биха предложили шефовете на бирата за research&development
или шефовете на salle от mysql/sun

Не увъртам - казах го максимално ясно. Според мен си overqualified, а аз нямам желание да обеснявам дълго и продължително на подобни хора, защо тяхната идея няма да сработи. Играл съм го това упражнение, не ми хареса (когато е по служба) и мога да го правя само по форуми.
ПП
Споменах че съм тъп но за сметка на това упорит. Мога да повторя това което написах по много начини, много пъти.
Ако можеш да го разбереш - добре, ако не можеш - мерси за това че опита да помогнеш.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

е най после описа филма за overqualified в които опитваш да ме сложиш

ама не е така от моя страна:
всеки ще си работи по неговите си неща, по неговия си начин
определено може да направя нещата и с транзакции, и с изчакване, и със заключване и ако се замисля по дълго може да намеря още няколко варианта или под варианти, като всеки вариант си има особености но все може да се ползва

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

виждал съм доста дето си мислят че може да ме убедят в нещо а се оказва че аз им отварям очите, тоест виждал съм доста пъти че виждам по далече от колкото предполагат такива като теб

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

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Баси, колко съм тъп ...
Как не се сетих за тва с изчакването, като го имах същия проблем ...
А и не беше много натоварена база, мало над 42к заявки в минута ... ;>
Перфектно щеше да ми пасне :>

браво поредния смешен повърхностен коментар участващ в състезанието с буш

ако се напише да следи времето за update (щото не се кешира) може да се ползва и при претоварване

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

и други има такива и сте доста смешни

има една препоръка която явно никога не е стигала до вас - че машините се пропоръчва да се товарят под границите на възможностите а не да се претоварват

ама кво ви пука на вас, сигурно единственото важно е да настигнете буш по неадекватно поведение

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

май не забеляза че варианта с изчакването е когато чакат реални потребители, тоест за тях е все едно дали чакат 0,1 сек или 0.001 сек

ако не са реални хора тогава не става

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Пука ми приятелю, щото машините с които работя почват от базова цена 80К евро, и повярвай ми, там шефовете не разбират от оправдания "Ма то така е по добре да е наравено, кво като ще дадем още 20К евро за скапано написания код" ...
p.s. не става дума за MySQL при мен, за DB400 иде реч ...
Ма на теб какво ти пука, ти пари за машини не даваш и мощна машина за теб е 4 процесорен пентиум с 8 гиги рам ... ;>

май и ти почна като бирата да ме вкарваш във филм които няма нищо общо с реалноста

кво е тва "20К евро за скапано написания код"?

начина с изчакването не отнема допълнителни ресурси щото процеса заспива за малко и не товари машината че да са необходими допълнителни ресурси(за които да се плаща)

разчита се че е все едно за потребителите дали ще чакат половин секунда или хилядна от секундата

така че никви допълнителни 20К евро не са необходими а само да се замислиш малко

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Абе човек, колко хора трябва да ти кажат, че това с изчакването не е решение, за да се съгласиш?

Няма как да знаеш с абсолютна точност колко ще отнеме заявката (процесът от заявки), т.е. колко да е точно това изчакване. Няма начин. Което значи, че по този начин първо, че пилееш безценно процесорно време, понеже чакаш за нещо, за което може и изобщо да не трябва да чакаш, и второ, че не можеш да гарантираш със сигурност, че времето за изчакване няма да е равно на времето за обработка и по този начин отново двама потребителя да попаднат на един и същи запис.

"Договор, подписан с Русия, струва по-малко от хартията, върху която е написан!" - Бисмарк

Струва ми се, че това вече беше предложено, но все пак и аз да добавя моите 50 стотинки.

Съдържаниет е скрито
Влезте за да го видите

UPDATE

  customer

SET

  locked_by_user_sid = 666

WHERE

  locked_by_user_sid IS NULL

AND



...



LIMIT

  1;

SELECT



  ...



FROM

  customer

  

  ...



WHERE

  locked_by_user_sid = 666;

UPDATE

  customer

SET

  locked_by_user_sid = NULL

WHERE

  locked_by_user_sid = 666;

Редактирано от Dakota на 06.01.09 17:58.

приличаш на поредния дето пробва да ме вкара в някъв филм

и 100 души да дрънкат глупости всеки с по 100 години опит това няма да превърне една глупост в нещо смислено

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Еми пич, дай да хвърляме зарове, за какво да пишем софтуер като пак случайно и тайнствено ще се случват някакви неща.

Съдържаниет е скрито
Влезте за да го видите

В отговор на:

---

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

---

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Редактирано от Dakota на 06.01.09 18:13.

оф не прочел и не разбрал което съм писал, ето някои неща

случайните грешки са известни, понякога се случва нещо което го няма в кода, много рядко ама го има, пример за тва е когато стане време да се инсталира отново windows ама не е точно същото, има и много други такива примери ама не ми се пише

тва че някои ще чака десети от секундата или милисекунди е без значение за реални хора както е случая

ако не си чувал оптимизиране се препоръчва да се прави само когато наистина е необходимо, когато има bottle neck а не когато някои като теб чел недорабрал дрънка глупости

ресурси на процесора не се пропиляват щото се изпълняват нишки, докато спи едната процесора изпълнява други

ето тва което предлагам описано по твоя начин:
1. отива кола на кръстовище и гледа светофара, ако не свети червено натиска бутон да се смени от жълто в зелено
2. гледа дали не е натиснал някои заедно с него бутон от друга страна на кръстовището
3. ако има едновременно натискане на бутона за зелено този които е натиснал по късно се отказва, лесно става щото при натискане на бутона всеки получава пореден номер
4. след това като вече е светнало зелено минава

сега вече разбра ли?

предлагам вместо да дрънкаш глупости да признаеш че не си прав и да разбереш що не заслужава да пиша друг път тук

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

В отговор на:

---

тва че някои ще чака десети от секундата или милисекунди е без значение за реални хора както е случая

---

ми тва е въпрос на настроики на базата и приложението

тези заявки за които става дума в случая са прости и е логично да стават за милисекунди при днешния хардуер, само малоумен може да си пусне базата на калкулатор или да претовари машината че прости update или select да се изпълняват за секунди

може да се мери времето на някоя заявка която не се кешира и по това да се вижда че машината е претоварена и въобше да се отказва обработка, логично е да отказва когато е претоварена

така че случая които описваш не е сериозен или е въпрос на настроика на базата и приложението

Съдържаниет е скрито
Влезте за да го видите

Ами все пак става въпрос за разработка.
И се е случвало да генерираме много "интересни" заявки. Не знам дали споменах ама много маймуни работят по клоните.
Та - преглеждаме си и лога с бавните заявки, чистим ги, когато са в нашето поле, иначе докладваме.
Но ги има.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

ми тва за което пиша е възможно най простите варианти на select и update
някъде май бях писал и формат
така че тва за което пишеш не се отнася за случая

иначе ако все пак измислите такава заявка за този сценарии които обсъждаме може да се коригира и опитимизира кода, заявката и базата така че да става за милисекунди

казано по друг начин не е целта да се покрият всички възможни глупости които може да измислят девелоперите а да се предложи код които върши работа

Съдържаниет е скрито
Влезте за да го видите

Ама хич не се отнася да знаеш.
Въобще. Виждал съм как скрипта докато плейва някакво късо съобщение - 2 - 3 секунди и губи връзка със сървъра.
И аз ровя по моите скриптове, докато накрая огледах БД.
Въобще няма нищо общо - прав си.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

тва май е няква ирония описана неясно като заданието на задачата

значи ако системата при вас е боза и се държи странно това не значи че такова поведение е нормално

като гледам твоето отношение и като каза че вашите шефове се чудят как да минат по евтино е логично системата ви да е зле поддържана и за това се държи странно ...

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

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

На твое място не бих се хАбил да му "отварям очите", а вместо това да получавам обяснения какво било положението в нечия фирма или някакви класации -- пълни детинщини!

За съжаление когато става дума за бази данни, индустрията е пълна с

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

определено не отговарям на точките които си описал:
1. Lack of knowledge and understanding of, and appreciation for data fundamentals in general, and relational concepts, principles and methods in particular

тука не става за Lack of knowledge а по скоро са ми ясни неща които са извън обхвата на твоя мозък, тоест знам че нормалния и препоръчителен начин на работа е да няма съществени забавяния, тоест може да се разчита че тва в масовия случай: простите заявки се изпълняват за милисекунди(когато приложението е проектирано добре и когато е настроена базата)

2. Unwillingness to let 1 stand in the way of pronouncing extensively on the subject

това се отнася за теб а не за мен щото си търсиш тъпи оправдания за глупостите

3. Inability and/or unwillingness to address evidence/proof of 1, and/or to reason

това се отнася за теб а не за мен щото си търсиш тъпи оправдания за глупостите

4. Lack of interest—often admitted—in truth and correctness

опредлено имам интерес и даже питам за мнения а ти си този дето си търси тъпи оправдания за глупостите

5. Primary focus on self promotion and appeasement of the industry by riding fashion fads, or telling (uninformed) audiences what they want to hear

това пак се отнася за теб ....

забележи че и индийката от статията и тя си вярва на глупостите подобно на теб, ама за 11 години в затвора може успее да разбере за какво става дума

теб като те гледам 11 години може да не ти стигнат ама може да пробваш

Съдържаниет е скрито
Влезте за да го видите

пак ме бъркаш със себе си

разбирам те за такива като теб е нормално

Съдържаниет е скрито
Влезте за да го видите

А бе моята цел вече е да схвана за какво се бори. Щото явно не си търси работа.
По скоро е чисто тролене вече.

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

тва за което се боря е за забавление, не го ли написах ясно?

като гледам нивото този форум за друго не става

между другото що ми изтриха темата? щото не можете да разберете че съм прав или щото не ви стига куража да признаете че съм прав?

Съдържаниет е скрито
Влезте за да го видите

А стига бе - ти не си наясно на кого трябва да поставиш този въпрос....

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

ми рядко пиша и почти само чета и не съм обърнал внимание на подробностите

сигурно трябва да поставя въпроса на дакота или на вълк

ама дакота е замесен и сигурно като не му изнасят фактите ще увърта а вълк ще го подкрепя

така или иначе не ми се занимава да споря, като нивото тук не е подходящо има много други форуми

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Ми като си overqualified за този форум - какво дириш тук?

Bеer? Mоre?

Съдържаниет е скрито
Влезте за да го видите

ми нали писах - за забавление пиша тук

като не става за работа поне може да ме разсмива, смеха е полезен за здравето сигурно знаеш

а и не е толкова просто
както писах overqualified е несериозно определение на свободния пазар

Съдържаниет е скрито
Влезте за да го видите