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

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

В какой момент с ним станет неудобно работать? Я про это и спрашиваю. Я не топлю за MySQL, я просто пытаюсь разобраться куда и во что лучше.

народ, не совсем могу понять. есть задание, сделать сервис по поиску туров: есть админ и пользователь. Админ один , но он может давать права админа юзерам

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

или это в приложении делается?

или я что-то не правильно понимаю ... T_T

народ, не совсем могу понять. есть задание, сделать сервис по поиску туров: есть админ и пользователь. Админ один , но он может давать права админа юзерам

любой админ может права выдавать? или только тот, который изначальный?

изначальный

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

три уровня

т.е. типа privileges_level = 0 - суперадмин. privileges_level = 1 админ priveleges_level =2 - обычный смертный

спасибо, интересная идея)

В какой момент с ним станет неудобно работать? Я про это и спрашиваю. Я не топлю за MySQL, я просто пытаюсь разобраться куда и во что лучше.

ну буду честен, с полем json в мускуле я не работал, потому за производительность поиска по этому полю не могу рассуждать =\ так что все мое мнение это имхо. ну и поиск, Как мне кажется, будет все равно быстрее работать по отдельным полям в мускуле, чем по жсону единому

спасибо, интересная идея)

да самая простая идея, что хоть ты

ну буду честен, с полем json в мускуле я не работал, потому за производительность поиска по этому полю не могу рассуждать =\ так что все мое мнение это имхо. ну и поиск, Как мне кажется, будет все равно быстрее работать по отдельным полям в мускуле, чем по жсону единому

В принципе, как я уже говорил, я загнал их все, предварительно нормализовав в SQLite, для пробы. Выборки мееедленные... Но и файл 265 метров, впрочем.

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

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

а такую фигню стоит во что-то типа мускуля\постргре все же пихать, имхо

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

Это почему?

ну я тоже думаю что нужно nosql юзать

ну я тоже думаю что нужно nosql юзать

Чем лучше NoSQL, чем нормализованная реляционка, в данном случае?

Чем лучше NoSQL, чем нормализованная реляционка, в данном случае?

а данные добавляться не будут?

Будут. Раз в день. По скрипту.

Чем лучше NoSQL, чем нормализованная реляционка, в данном случае?

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

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

я тоже так думаю

Да ну, там всё в одну таблицу отлично кладётся. Не вижу никаких проблемы выбирать из одной-то таблицы...

Да ну, там всё в одну таблицу отлично кладётся. Не вижу никаких проблемы выбирать из одной-то таблицы...

в одной таблице это не нормализованная бд

еще такое https://www.couchbase.com/preview/couchbase-server-4-0 вот советуют

в одной таблице это не нормализованная бд

++

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

в одной таблице это не нормализованная бд

Запись - факт поиска, у него нет связей. Никаких.

угу... а надо будет тебе выбрать только тех юзверей у которых accept language ru

если бы у тебя все accept language были в отдельной таблице и связаны с юзверями как многие ко многим, то тебе только айдишники надо было бы выбрать

а так придется делать текстовый поиск по json полю мускуля

если бы у тебя все accept language были в отдельной таблице и связаны с юзверями как многие ко многим, то тебе только айдишники надо было бы выбрать

Нет юзверей.

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

Есть только факт поиска.

у тебя там search "" user ""

это просто отграничение данных.

и тебе с ним не придется работать?

что в этом оъекте данные о пользователе, анонимные.

в таблице у тебя что только данные которые в search лежат?

Я не могу их связывать. Они анонимные.

и что?

не улавливаю пока проблемы

допустим тебе надо выбрать все страницы которые искали юзвери с последним хромом

И то что нет сущности "пользователь"

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

не будет таких задач?

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

Это поле типа int(2) - 0/1 searchIncognito

Точнее даже null || !null

окей, как ты все хранишь в sqlite, потому что я сейчас вилами по воде угадываю, а мне так не нравится

а пример задачи выборки?

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

Количество поисков через какой-либо поисковик, в определённые дни, под определённым user-agent.

ну и лично я acceptlangs разбил на многие ко многим

может поудобнее будет сделать searchEngine целым и определть поисковики битовой маской? так же с acceptLangs (если вариантов не много)

может поудобнее будет сделать searchEngine целым и определть поисковики битовой маской? так же с acceptLangs (если вариантов не много)

дальнейшая поддержка будет геморной не? плюс хранить где-то инфу о том, какая маска какому браузеру\языку соответствует

плюс придет кто-то новый, ему тоже вникнуть надо будет время

дальнейшая поддержка будет геморной не? плюс хранить где-то инфу о том, какая маска какому браузеру\языку соответствует

Тут ещё такой нюанс - это просто пэт-проджект. Не сочтите за рекламу - https://chrome.google.com/webstore/detail/phototracker-lite/opadloaiiilnjibkfkopaokgfkhggjgb

плюс придет кто-то новый, ему тоже вникнуть надо будет время

define('SEARCH_GOOGLE', 1 << 0); define('SEARCH_YANDEX', 1 << 1); define('SEARCH_BING', 1 << 2); define('SEARCH_PORNOHUB', 1 << 3);

долго вникать в такое?

Хранится всё это на слабеньком VPS с 512 метрами памяти, которые отдавать на растерзание прожорливому MySQL не сильно хочется ради пары тройки выборок в месяц...

плюс придет кто-то новый, ему тоже вникнуть надо будет время

Никто не придёт... )))

долго вникать в такое?

в какое?

в какое?

на одно сообщение выше - кусок исходника с константами (как раз про битовые маски)

ERROR: S client not available

тогда дня 2

если с нуля, и не знаешь что есть разные системы счисления

тогда дня 2

это диагноз

долго вникать в такое?

а если я буду искать сразу в мускуле?

без констант на пыхе

а если я буду искать сразу в мускуле?

плохо тебе значит, если не прочитав доку (или хотя бы комменты в исходниках) - полез в БД.

Ну вот сейчас у меня 1 rows returned in 6003ms from: SELECT COUNT(id) FROM searches WHERE searchGoogle = 1; ?

а это всё, что есть? или индексы потом поставил?

это хорошо, если где-то есть эти исходники

Ну вот сейчас у меня 1 rows returned in 6003ms from: SELECT COUNT(id) FROM searches WHERE searchGoogle = 1; ?

индексыы

я же говорил уже

Не, ещё не расставлял.

просто как то не комильфо юзать целый INT (а он вроде как 4 байта, а ещё и индекс), ради того, что searchGoogle может быть только 0 или 1.

Не, ещё не расставлял.

поставь индекты на поля search***, а перед этим сделай их TINYINT

поставь индекты на поля search***, а перед этим сделай их TINYINT

Это как бы SQLite, в нём нет TINYINT. И он сам выбирает 1байтовый тип для таких полей.

Это как бы SQLite, в нём нет TINYINT. И он сам выбирает 1байтовый тип для таких полей.

о, тогда сорян. я всё о мускуле думаю.... %)

Это как бы SQLite, в нём нет TINYINT. И он сам выбирает 1байтовый тип для таких полей.

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

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

Не услышал доводов, прости.

?‍♂️твое дело. тогда просто не надо ныть что оно тормозит

?‍♂️твое дело. тогда просто не надо ныть что оно тормозит

С индексами не тормозит. )

1 rows returned in 138ms from: SELECT COUNT(id) FROM searches WHERE searchGoogle = 1;

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

1 rows returned in 138ms from: SELECT COUNT(id) FROM searches WHERE searchGoogle = 1;

это по-твоему не тормозит? o_O

Ну тогда и подумаю про миграцию. Или подумаю про то чтобы посчитать старые и удалить. )

это по-твоему не тормозит? o_O

246 тысяч записей.

246 тысяч записей.

тут всего селект по одной таблице

Нет, для SQLite - не тормозит.

тут всего селект по одной таблице

он не хочет никого слушать. у него стало искать не 6 секунд.а 136мс, все збс

забей

Чуваки, выговорите что не стоит юзать SQLite но не говорите почему...

Опять же, он не жрёт оперативку пока не нужен...

Чуваки, выговорите что не стоит юзать SQLite но не говорите почему...

А ты смешной