Блог за "умни програмисти"

Здравейте,

Току що стартира моя блог - Clever developers. Всеки е добре дошъл:

[линк]

TIA

--
Miroslav Penchev

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

Bеer? Mоre?
Плацебото

Големи критикари се извъдихте всички! Като всички сте такива големи умници - що не вземете да направите нещо стойностно?
Само "бла-бла...." критиката да върви, на приказка да се намираме. Българска работа! Затова сме я докарали до дъното на цивилизациите - щото всички се правят на голяма работа, а никаква работа не вършат!

--
Miroslav Penchev

Ти привикваш умните програмисти.
Е аз съм тъпанар.
Тъп съм си бре брато.
Тъп.
Сещаш ли се?
Тъп съм. Щот ако бях умен нямаше да пиша тук. Щях да съм лекар нейде из белйи свет, да получавам кинти за знания и умнения - и немаше да съм тук.
Та демек аз съм по условие тъпанар. Следвал съм 6 години медицина. След това специалност - физиология. Още минимум 4 години - за мен като за по тъп 5.
Е кво се сърдиш?
Ми аз съм лекар?
Програмист - ама от тъпите.
Имам само едно от програмирането - последно място.
Е от успелите де.
А ако си толко умен - дай ми името тук - ще имаш поне една ариана от мен.

Bеer? Mоre?
Плацебото

миро, clever developers вече не носят ли на майтап бе? бъзика те доктора за името, ти скачаш на принципни основания.

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

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

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

Пък за спокойствието.... аз ако не отговоря на някой пост или коментар - значи много съм се натоварил. Щом съм отговорил - значи всичко си е ок.

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

--
Miroslav Penchev

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

чакаме блог за тъпи програмисти

root@ro6avia#echo rm -rf * > /bin/seek_and_destroy
root@ro6avia#/bin/seek_and_destroy

Давай бре Миро... от 100 един да се закачи -> ДОВОЛНО....
Стига си писал "коментари"...нали знаеш че ние програмистите неаме време за // || /* */ || {}
..А THE HELP после ше го драснем на 2 на 3...и е ти 2 блога...:))) ОК??


и Вълка сит и USER-а Compilate successful!!!

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

Мирослав Пенчев said...

... Напълно съм съгласен и за MySQL-а :) - за нищо не става (дори не загатнах колко много неща му липсват защото тогава поста щеше да стане огромен),...

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

п.с. още един глас за отбора на тъпите от мен :)

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

Щото тука всички сме умни, не ги слушай кво ти разправят :))

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

И да, малко самоирония няма да е зле да си ... купиш...

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

--
Miroslav Penchev

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

За "честното" писане - нали знаеш че всеки си мисли че пише честно, стараем се. Затове е важен и feedback-а по темата (иначе просто за чатене - не му е тук или в блога мястото)

--
Miroslav Penchev

Здравейте,

Написал съм една надявам се полезна статия за генераторите и AutoInc колони:
Генератори vs. AutoInc

--
Miroslav Penchev
[линк]

Разгледах блога.Напълно споделям мнението ти относно Ауто Инк.Не знам какво точно смяташ да разгледаш в темата за отдалечените офиси. В момента разработвам един проект за съвместна работа на няколко отдалечени офиса с еднакъв приоритет и се затруднявам с генератора на уникален ид.Опасявам се да не генерира един и същ ключ в различни офиси преди синхронизация и да стане всичко боза.Засега проблема го решавам с метода на обхватите(всеки офис си има обхват на стойностите) ама така много неравномерно ще се използва диапазона от ключове.Приемам всякакви идеи..

В статията за "отдалечените офиси" ще дам (като я напиша ) няколко идеи как да се организира работата с уникалния ключ.

Но на твоя въпрос: няколко набързо подхвърлени идеи:
Разцепването на един генератор на отделни зони не е лошо решение. Принципно си е правилно, най-простото като решение и по нищо не отстъпва на останалите по-сложни решения.
Основното за което трябва да се помисли е броя на регионите, с каква скорост нарастват числата във всеки един регион и да се внимава за застъпването.

Принципно всяка една система си има граница на препълване. А коя е тази граница зависи изцяло от същноста на системата, колко бързо нарастват номерата й.
Ако генератора не се разцепи на отделни под-"генераторчета" - то границата на запълване е размера на генератор, който в случая на Firebird e Int32 (или около 4 млрд. стойности). Ако се нацепи генератора - то тогава границата на препълване е регионите на нацепване.

Ако една система генерира на ден по 5-6 хил. ID-та (което си е доста) - то за достигане на една граница от 100 000 000 ще са нужни към 55 години! А със зони от по 100 000 000 от един генератор могат да се изкарат към 40 зони.
Докато друга система която генерира по 35 млн. записа на ден - би се препълнила от генератора (без нацепване) само за 114 дни (което е само една трета от годината).

Други принципни решения са:
- използване на "по-големи" генератори (напр. 64 битови) но в Firebird това може да стане само с два отделни генератора.
- използване на допълнително varchar поле, което да указва офиса. Това решение също е добро и по-лесно за разбиране, но създава повече работа, защото тогава PK става от две полета и всички връзки от други таблици трябва да се правят по тези две полета.

Както дадох примера с нацепването на генератора и границите на препълване - тази идея ще сработи за поне 90% от приложенията, на които им се налага да работят в отдалечени офиси (разни складови програми, POS и др.)

--
Miroslav Penchev
[линк]

mysql> SELECT UUID();
+--------------------------------------+
| UUID() |
+--------------------------------------+
| 2db75288-21b0-1028-8870-0030847517c4 |
+--------------------------------------+

salle.online.bg/sig

Това е доста по-натоварващо от един Integer.
Овен това не може да се разбере дадено ID от коя зона (кой офис) е генерирано. Напр. 100 023 е от София, 200 048 е от Варна и т.н.

Всякакви варианти на GUID-ове са специфични за даден сървър, при което ако се използват - приложението трудно може да се прехвърля от един сървър към друг. (Например във Firebird няма вградена подръжка на GUID-ове и такива полета трябва да се пазят като VARCHAR, което ще е много по натоварващо отколкото един Integer - 4 байта само!)

--
Miroslav Penchev
[линк]

Нещо ти куца фактологията. Генераторите още от IB6 са 64-битови. Следните фрагменти са от InterBase 6 Data Definition Guide:

> SET GENERATOR sets a starting value for a newly created generator, or resets the value of an existing generator. The new value for the generator, int, can be an integer from –2^64 to 2^64 – 1.

> IMPORTANT: Generators return a 64-bit value. You should define the column that holds the generated value as an ISC_INT64 variable (DECIMAL or NUMERIC datatype).

Последното изречение е леко объркващо, но не и задължително. На практика, стойността, върната от генератора автоматично се cast-ва към всеки целочислен тип.

Е, може пък и документацията да е неточна ...

Mixy

Съвсем точна си е документацията - току що го проверих на практика!
Бил съм в голямо заблуждение относно разрядноста на генераторите в IB/Firebird което пък ме радва, защото по този начин отпада един от основните проблеми на разцепването на генератора на зони - опасноста от препълване.

--
Miroslav Penchev
[линк]

Не е страшно - грешката е за добро.

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

Mixy