По някога ме чуват - та съм спестил някои "екстри".
Ама все пак са си шефове.
За цената - те си знаят. Аз ще опитам със 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.