- есть поле char(4) c индексом, в котором хранится строковый идентификатор, который обозначает тип объекта

- всего в системе 30-40 типов объектов, ну может быть 50-60, но порядок именно такой - десятки, не сотни и не тысячи

пара вопросов:

1) насколько существенна разница в скорости обработки join запросов между строкой type = 'ab' и строкой type = 'abcd'

2) в чем принципиальная разница между размещением условия на фильтрацию этого поля, размещая в условиях джоина join on (... and type = 'ab') vs вариант с размещением этого условия в where-секции, то есть вот так join on (...) where type = 'ab'

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

miksoftCygapb-007пропущено...
Честно говоря, не вижу разницы в поиске 'abcd' и, после приведения типов (char(4)), 'ab__'Если в обоих случаях тип char(4), то разницы не будет.
Я подразумевал разницу между char(2) и char(4) (из заголовк топика).

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

Раз уже зашла такая маза, то осталось спросить как в этом случае будет вести себя char(4) но с индекском char(2)? ближе к скорости char(4) или ближе к скорости к char(2) или вообще это как бы почти что char(3)?

А информация о том, что type = 'ab' и type = 'abcd' на char(4) имеют одинаковую скорость поиска - это очень крутая информация. Спасибо!!

miksoftCygapb-007пропущено...
Плюс еще одна табличка с расшифровкой кода ;-)При нескольких десятках двухбуквенных сочетаний, подозреваю, ее все равно не избежать :)

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

Мы уже давно пользуемся этим приемом и поэтому тихим субботним вечером в этой теме я лишь хотел узнать цену подобного технического решения, то есть насколько сильно мы теряем. В данном случае, я понял, что когда задан char, то можно смело пользоваться идентификаторами на всю его длину.

Что касается таблицы с расшифровками, то этого не требуется, потому что буквы означают таблицы, которые используются в системе. Две буквы приходиться использовать когда в системе есть таблица pages и posts, тогда не понятно что означает буква 'p', поэтому мы используем 'pa' и 'po'

В результате же сегодняшней темы, я уже написал всем рассылку, что можно смело использовать 'page' и 'post', потому что скорость все равно будет та же самая.

miksoftLumixбуквы означают таблицы, которые используются в системеНе знаю почему, но мне этот метод очень не нравится. Попахивает плохим проектированием БД.

в этой таблице хранятся флаги по каждому пользователю в отношении разных объектов




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

ну а чтобы тогглы робили на insert ... update on duplicate key мы юзаем констранту unique(userId, tableMark, tableRowId)

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

MasterZiv, ок! Спасибо!! Особенно очень ценно про диски и память.

Изначально в основе всей этой ветки не было какой-то конкретной проблемы, которая прямо сейчас остановила весь продакшен. В основу этой ветки были положены какие-то мелкие глубинные давние страхи, которые появилось время развеять и я их развеял. В простонародье эти страхи вообще именуют "тараканами в голове". Вот я этих тараканов почистил и теперь с чистой душой буду воспринимать все те типы данных, которые сейчас используются в продакшене.

miksoft, неее... сколько тестов не проводили, тараканы все равно остаются. А вот пообщались тут предметно за выхи и они все сдохли. :-)