Логично для embedded. Логика таковой системы в софте ведь, не в БД?
Ведь никто не жалуется, что MSAccess хранит логику в кодах, а в БД хранит только данные (и правила целостности).
Зато я слышал, что MSAccess просто рушился целиком вместе с данными при приближении размера файла к 256МБ. Без восстановления.
Есть ли какие-то проблемы коллективного доступа, ограничений размеров, надёжности ATOM для SQLite? Может какие-то другие недостатки? SQL-92/2008 поддерживается паршиво?
Может быть есть аналитическая статья, которая перечисляет эти недостатки грамотным техническим и философским языком?
У меня к badoo такой личный вопрос, не относящийся к топику:
Когда рапортуешь, что в некой анкете фотография чужая (обычно знаменитости), требуется указать имя изображённого. Для этого приходится через задницу выуживать фото (простые методы вами заблокированы), чтобы впихнуть в google images или tineye и, наконец, идентифицировать эту знаменитость.
В результате badoo никаких действий по поводу данной анкеты не предпринимает.
То есть, это никакой не random, если вы знаете в чём суть закладки.
Не понимаю замысла автора… Если он не знает сути, то зачем изображает, что знает? Если знает, то зачем мутит ерунду что читатели должны знать?
Но впечатление такое, что именно автор не знает, зато снобирует, будто знает.
Даже если автор теперь прочтёт что сам наапдейтил в статье — мнения о его невежестве это не исправит.
Подпись надо было ставить (был некий парень, который раздал свою легальную подпись для всего мира), либо качать оперу с подписью — она там отдельно на сайте лежала.
Любопытно, будет ли подписка на «приоритетную маршрутизацию по сравнению с остальными», «приоритетную парковку» и т.д.?
Нормальный fremium сервис получится ;-)
А не вышло бы так, что пространство с отношением периметра к диаметру равным трём оказалось бы очень выпуклым?
Тут-то и подкрадывается «Большой Пц» в виде «Большого схлопывания». А поскольку метрика уж очень чрезмерно выпукла, то БПц/БСхл наступит очень чрезмерно быстро. Типа через минут 5 после Большого взрыва.
2) Нам очень повезло, что текст инсталлятора всё-таки можно прочесть не дольше, чем за 120 секунд (без учёта собственно EULA ;-))
Я попытался прочесть условия одного тут банка по выпуску виртуальной. Хлам с дырами и граблями. По ссылкам заставил распечатать клерка страниц с полсотни, и это не все ссылки я «разрешил». Три вечера читал. Из запомнившегося: банк может отказать в услуге без возмещения списания, если транзакция или прочие сложившиеся гороскопы не соответствуют правилам ...(бла-бла)… и Шанхайского национального банка. Печатать и читать правила из Китая эдак в полтыщи-полмиллиона страниц я уже не захотел.
От рассказанного-показанного Сноуденом неуправляемый восторг и намерение неотвратимо сделать так же. Это ж до скольки вещей самостоятельно не додумались-то, ан вот, товарищ продемонстрировал расширенные горизонты! ;-)
«Но получается „как всегда“». :-D
Ведь никто не жалуется, что MSAccess хранит логику в кодах, а в БД хранит только данные (и правила целостности).
Зато я слышал, что MSAccess просто рушился целиком вместе с данными при приближении размера файла к 256МБ. Без восстановления.
Есть ли какие-то проблемы коллективного доступа, ограничений размеров, надёжности ATOM для SQLite? Может какие-то другие недостатки? SQL-92/2008 поддерживается паршиво?
Может быть есть аналитическая статья, которая перечисляет эти недостатки грамотным техническим и философским языком?
Каковы недостатки SQLite?
Когда рапортуешь, что в некой анкете фотография чужая (обычно знаменитости), требуется указать имя изображённого. Для этого приходится через задницу выуживать фото (простые методы вами заблокированы), чтобы впихнуть в google images или tineye и, наконец, идентифицировать эту знаменитость.
В результате badoo никаких действий по поводу данной анкеты не предпринимает.
Вопрос: нахрена это всё в таком случае?!
Не понимаю замысла автора… Если он не знает сути, то зачем изображает, что знает? Если знает, то зачем мутит ерунду что читатели должны знать?
Но впечатление такое, что именно автор не знает, зато снобирует, будто знает.
Даже если автор теперь прочтёт что сам наапдейтил в статье — мнения о его невежестве это не исправит.
Нормальный fremium сервис получится ;-)
(И наеборот)
Тут-то и подкрадывается «Большой Пц» в виде «Большого схлопывания». А поскольку метрика уж очень чрезмерно выпукла, то БПц/БСхл наступит очень чрезмерно быстро. Типа через минут 5 после Большого взрыва.
2) Нам очень повезло, что текст инсталлятора всё-таки можно прочесть не дольше, чем за 120 секунд (без учёта собственно EULA ;-))
Я попытался прочесть условия одного тут банка по выпуску виртуальной. Хлам с дырами и граблями. По ссылкам заставил распечатать клерка страниц с полсотни, и это не все ссылки я «разрешил». Три вечера читал. Из запомнившегося: банк может отказать в услуге без возмещения списания, если транзакция или прочие сложившиеся гороскопы не соответствуют правилам ...(бла-бла)… и Шанхайского национального банка. Печатать и читать правила из Китая эдак в полтыщи-полмиллиона страниц я уже не захотел.
«Но получается „как всегда“». :-D
При этом подозреваю, что внутри Ирана пропаганда достижений Ирана вполне оголтелая.
Но куда соединится VPN — уже ваша ответственность.
P.S.Галочка «VPN» появляется после опции settings\VPN Support.
По критерию «ПСП от ключа».
То есть классов шифрования только два: подстановка и перестановка.
Плюс кодирование как таковое в качестве третьего пути, то есть замена одних фраз другими фразами, согласно оговоренной кодовой книге.
Информация специфическая и полезная. Продолжать нужно!
(Так же ждём описание проблем и решений high-load от команд порнопорталов!)