Вопрос заключается в следующем. Как влияет кол-во столбцов на скорость работы SELECT.
Просто нужно создавать или множество столбцов, что-то типа битовой маски, или сделать один строковый столбец и от туда выбирать по LIKE '....' нужные строчки.
Подскажите.
Можно конечно проверить все самому, создав оба варианта и посмотрев статистику, но может кто с подобным сталкивался.
Re: Скорость выборки данных СУБД если много столбцов
Здравствуйте Манченко Сергей, Вы писали:
МС>Вопрос заключается в следующем. Как влияет кол-во столбцов на скорость работы SELECT.
Замедляет, однозначно.
МС>Просто нужно создавать или множество столбцов, что-то типа битовой маски, или сделать один строковый столбец и от
А множество, это примерно сколько?
>туда выбирать по LIKE '....' нужные строчки.
С LIKE точно не стоит связываться.
МС>Подскажите. МС>Можно конечно проверить все самому, создав оба варианта и посмотрев статистику, но может кто с подобным сталкивался.
А почему бы тебе не использовать третий вариант? Сделать отдельную таблицу IDFlag и писать в нее пары: ID записи, и флаг записи. Для каждого ID будет ровно столько записей, сколько для него "проставлено" различных флажков. Если разных флагов много, то это, ИМХО, лучший вариант. Можно будет повесить на Flag,ID кластерный индекс.
Re[2]: Скорость выборки данных СУБД если много столбцов
Здравствуйте Lexey, Вы писали:
L>Здравствуйте Манченко Сергей, Вы писали:
МС>>Вопрос заключается в следующем. Как влияет кол-во столбцов на скорость работы SELECT.
L>Замедляет, однозначно.
МС>>Просто нужно создавать или множество столбцов, что-то типа битовой маски, или сделать один строковый столбец и от
L>А множество, это примерно сколько?
примерно 30-40.
>>туда выбирать по LIKE '....' нужные строчки.
L>С LIKE точно не стоит связываться.
LIKE — был на крайний случай
МС>>Подскажите. МС>>Можно конечно проверить все самому, создав оба варианта и посмотрев статистику, но может кто с подобным сталкивался.
L>А почему бы тебе не использовать третий вариант? Сделать отдельную таблицу IDFlag и писать в нее пары: ID записи, и флаг записи. Для каждого ID будет ровно столько записей, сколько для него "проставлено" различных флажков. Если разных флагов много, то это, ИМХО, лучший вариант. Можно будет повесить на Flag,ID кластерный индекс.
Этот вариант конечно подходит, но по независящим от меня причинам, все варианты с содинением таблиц, непримениы (так желает начальник), главное скорость . Но возможно именно такой вариант в данном случа будете самым быстрым и лаконичным. А флагов много не нужно, нужно лишь — есть флаг/нет.
Вопрос чайника — а что такой "кластерный индекс"?
Re: Скорость выборки данных СУБД если много столбцов
Здравствуйте Манченко Сергей, Вы писали:
МС>Вопрос заключается в следующем. Как влияет кол-во столбцов на скорость работы SELECT. МС>Просто нужно создавать или множество столбцов, что-то типа битовой маски, или сделать один строковый столбец и от туда выбирать по LIKE '....' нужные строчки.
Раз нужно что-то типа битовой маски, так и сделай на клиентской стороне упаковку/распаковку твоих флагов из битовых полей. Таким образом два DWORD дадут тебе до 64 полей Да/Нет и работать будет все влет.
---
С уважением,
Игорь
Re[2]: Скорость выборки данных СУБД если много столбцов
Здравствуйте Игорь Вартанов, Вы писали:
ИВ>Здравствуйте Манченко Сергей, Вы писали:
МС>>Вопрос заключается в следующем. Как влияет кол-во столбцов на скорость работы SELECT. МС>>Просто нужно создавать или множество столбцов, что-то типа битовой маски, или сделать один строковый столбец и от туда выбирать по LIKE '....' нужные строчки.
ИВ>Раз нужно что-то типа битовой маски, так и сделай на клиентской стороне упаковку/распаковку твоих флагов из битовых полей. Таким образом два DWORD дадут тебе до 64 полей Да/Нет и работать будет все влет.
Это сильно зависит от размеров базы. В таком варианта будет однозначный full table scan. При большой базе это кранты.
Re[3]: Скорость выборки данных СУБД если много столбцов
Здравствуйте Манченко Сергей, Вы писали:
МС>>>Вопрос заключается в следующем. Как влияет кол-во столбцов на скорость работы SELECT.
L>>Замедляет, однозначно.
МС>>>Просто нужно создавать или множество столбцов, что-то типа битовой маски, или сделать один строковый столбец и от
L>>А множество, это примерно сколько?
МС>примерно 30-40.
Да, прилично. Отдельными полями это хранить не весело. И индексы на них все равно делать будет бестолку. Т.ч. тут будет table scan. В таком варианте действительно лучше сделать все через битовое поле.
>>>туда выбирать по LIKE '....' нужные строчки.
L>>С LIKE точно не стоит связываться.
МС>LIKE — был на крайний случай
Ну, он наверное все-таки получше предыдущего будет, если база умеет делать full-text индекс. В противном случае его точно нужно сразу отбрость.
МС>>>Подскажите. МС>>>Можно конечно проверить все самому, создав оба варианта и посмотрев статистику, но может кто с подобным сталкивался.
L>>А почему бы тебе не использовать третий вариант? Сделать отдельную таблицу IDFlag и писать в нее пары: ID записи, и флаг записи. Для каждого ID будет ровно столько записей, сколько для него "проставлено" различных флажков. Если разных флагов много, то это, ИМХО, лучший вариант. Можно будет повесить на Flag,ID кластерный индекс.
МС>Этот вариант конечно подходит, но по независящим от меня причинам, все варианты с содинением таблиц, непримениы (так желает начальник), главное скорость . Но возможно именно такой вариант в данном случа будете самым быстрым и
Гхм. У тебя начальник что, спец. по БД? Если нет, то как он может указывать, как нужно делать, и что будет быстрее?
При больщой базе такой вариант однозначно будет самам быстрым.
>лаконичным. А флагов много не нужно, нужно лишь — есть флаг/нет.
МС>Вопрос чайника — а что такой "кластерный индекс"?
Это индекс, который еще и задает физический порядок хранения данных в базе. Вот только далеко не все базы умеют делать такие индексы (MS SQL Server умеет).
Re[3]: Скорость выборки данных СУБД если много столбцов
Здравствуйте Lexey, Вы писали:
L>Здравствуйте Игорь Вартанов, Вы писали:
ИВ>>Здравствуйте Манченко Сергей, Вы писали:
МС>>>Вопрос заключается в следующем. Как влияет кол-во столбцов на скорость работы SELECT. МС>>>Просто нужно создавать или множество столбцов, что-то типа битовой маски, или сделать один строковый столбец и от туда выбирать по LIKE '....' нужные строчки.
ИВ>>Раз нужно что-то типа битовой маски, так и сделай на клиентской стороне упаковку/распаковку твоих флагов из битовых полей. Таким образом два DWORD дадут тебе до 64 полей Да/Нет и работать будет все влет.
L>Это сильно зависит от размеров базы. В таком варианта будет однозначный full table scan. При большой базе это кранты.
От автора: Я тоже так подумал. База будет постоянно пополнятся, примерно раз в секунду.
Re[4]: Скорость выборки данных СУБД если много столбцов
Здравствуйте Lexey, Вы писали:
L>Здравствуйте Манченко Сергей, Вы писали:
МС>>>>Вопрос заключается в следующем. Как влияет кол-во столбцов на скорость работы SELECT.
L>>>Замедляет, однозначно.
МС>>>>Просто нужно создавать или множество столбцов, что-то типа битовой маски, или сделать один строковый столбец и от
L>>>А множество, это примерно сколько?
МС>>примерно 30-40.
L>Да, прилично. Отдельными полями это хранить не весело. И индексы на них все равно делать будет бестолку. Т.ч. тут будет table scan. В таком варианте действительно лучше сделать все через битовое поле.
кстати, может я чего не знаю, а есть ли в SQL операторы работы с битовыми масками? Но ведь можно использовать числовое поле в кач-ве битовой маски и построить соответсвующий запрос (это я еще подумаю).
>>>>туда выбирать по LIKE '....' нужные строчки.
L>>>С LIKE точно не стоит связываться.
МС>>LIKE — был на крайний случай
L>Ну, он наверное все-таки получше предыдущего будет, если база умеет делать full-text индекс. В противном случае его точно нужно сразу отбрость.
спасибо, уточню. База Informix.
МС>>>>Подскажите. МС>>>>Можно конечно проверить все самому, создав оба варианта и посмотрев статистику, но может кто с подобным сталкивался.
L>>>А почему бы тебе не использовать третий вариант? Сделать отдельную таблицу IDFlag и писать в нее пары: ID записи, и флаг записи. Для каждого ID будет ровно столько записей, сколько для него "проставлено" различных флажков. Если разных флагов много, то это, ИМХО, лучший вариант. Можно будет повесить на Flag,ID кластерный индекс.
МС>>Этот вариант конечно подходит, но по независящим от меня причинам, все варианты с содинением таблиц, непримениы (так желает начальник), главное скорость . Но возможно именно такой вариант в данном случа будете самым быстрым и
L>Гхм. У тебя начальник что, спец. по БД? Если нет, то как он может указывать, как нужно делать, и что будет быстрее? L>При больщой базе такой вариант однозначно будет самам быстрым.
какой есть ( переубедить его сложно, но можно
>>лаконичным. А флагов много не нужно, нужно лишь — есть флаг/нет.
МС>>Вопрос чайника — а что такой "кластерный индекс"?
L>Это индекс, который еще и задает физический порядок хранения данных в базе. Вот только далеко не все базы умеют делать такие индексы (MS SQL Server умеет).
а меня учили, что индекс (слово кластерный не было) как раз и задает физический порядок хранения записей. Ясно, спасибо.
Re[5]: Скорость выборки данных СУБД если много столбцов
Здравствуйте Манченко Сергей, Вы писали:
МС>>>>>Вопрос заключается в следующем. Как влияет кол-во столбцов на скорость работы SELECT. L>>>>Замедляет, однозначно. МС>>>>>Просто нужно создавать или множество столбцов, что-то типа битовой маски, или сделать один строковый столбец и от L>>>>А множество, это примерно сколько? МС>>>примерно 30-40. L>>Да, прилично. Отдельными полями это хранить не весело. И индексы на них все равно делать будет бестолку. Т.ч. тут будет table scan. В таком варианте действительно лучше сделать все через битовое поле.
МС>кстати, может я чего не знаю, а есть ли в SQL операторы работы с битовыми масками? Но ведь можно использовать
&,|,^
числовое поле в кач-ве битовой маски и построить соответсвующий запрос (это я еще подумаю).
Это уже предлагал IV. Плохо тем, что это все тот же full table scan.
>>>>>туда выбирать по LIKE '....' нужные строчки.
L>>>>А почему бы тебе не использовать третий вариант? Сделать отдельную таблицу IDFlag и писать в нее пары: ID записи, и флаг записи. Для каждого ID будет ровно столько записей, сколько для него "проставлено" различных флажков. Если разных флагов много, то это, ИМХО, лучший вариант. Можно будет повесить на Flag,ID кластерный индекс.
МС>>>Этот вариант конечно подходит, но по независящим от меня причинам, все варианты с содинением таблиц, непримениы (так желает начальник), главное скорость . Но возможно именно такой вариант в данном случа будете самым быстрым и
L>>Гхм. У тебя начальник что, спец. по БД? Если нет, то как он может указывать, как нужно делать, и что будет быстрее? L>>При больщой базе такой вариант однозначно будет самам быстрым.
МС>какой есть ( переубедить его сложно, но можно
Главное, что можно.
>>>лаконичным. А флагов много не нужно, нужно лишь — есть флаг/нет.
МС>>>Вопрос чайника — а что такой "кластерный индекс"?
L>>Это индекс, который еще и задает физический порядок хранения данных в базе. Вот только далеко не все базы умеют делать такие индексы (MS SQL Server умеет).
МС>а меня учили, что индекс (слово кластерный не было) как раз и задает физический порядок хранения записей. Ясно, спасибо.
Неправильно учили. Индексов на таблице может быть много. Как они все могут задавать физическое расположение?
Обычный индекс хранится отдельно от таблицы и содержит указатели на физические записи. Кластерный индекс содержится внутри таблицы и физически упорядочивает записи.
Re[4]: Скорость выборки данных СУБД если много столбцов
Здравствуйте Манченко Сергей, Вы писали:
ИВ>>>Раз нужно что-то типа битовой маски, так и сделай на клиентской стороне упаковку/распаковку твоих флагов из битовых полей. Таким образом два DWORD дадут тебе до 64 полей Да/Нет и работать будет все влет.
L>>Это сильно зависит от размеров базы. В таком варианта будет однозначный full table scan. При большой базе это кранты.
МС>От автора: Я тоже так подумал. База будет постоянно пополнятся, примерно раз в секунду. :(
Раз в секунду? И как долго она будет пополняться с такой частотой?
Н-да... Похоже, я несколько погорячился. :( Что хоть за база, на чем и под чем, может есть какое-то свое специфическое средство?
---
С уважением,
Игорь
Re[3]: Скорость выборки данных СУБД если много столбцов
Здравствуйте Манченко Сергей, Вы писали:
МС>Этот вариант конечно подходит, но по независящим от меня причинам, все варианты с содинением таблиц, непримениы (так желает начальник), главное скорость . Но возможно именно такой вариант в данном случа будете самым быстрым и лаконичным. А флагов много не нужно, нужно лишь — есть флаг/нет.
А много данных?
Может быстрее будет вынуть их на клиента заепить матрицу или многомерный массив и работать в памяти?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Скорость выборки данных СУБД если много столбцов
Здравствуйте Игорь Вартанов, Вы писали:
ИВ>Н-да... Похоже, я несколько погорячился. Что хоть за база, на чем и под чем, может есть какое-то свое специфическое средство?
Да, главный вопрос: что за задача?
Уж больно предпосылки не для базы данных. (Пополнение раз в секунду и битовый массив вместо информации).
А насчет полного сканирования таблицы — так это не от данных зависит, а от способа выборки. Ищи про равно предварительно собирая из флагов полное значение поля и все.
Короче, опиши саму задачу. Так будет проще дать разумный ответ.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Скорость выборки данных СУБД если много столбцов
Здравствуйте VladD2, Вы писали:
ИВ>>Н-да... Похоже, я несколько погорячился. Что хоть за база, на чем и под чем, может есть какое-то свое специфическое средство?
VD>Да, главный вопрос: что за задача?
VD>Уж больно предпосылки не для базы данных. (Пополнение раз в секунду и битовый массив вместо информации).
VD>А насчет полного сканирования таблицы — так это не от данных зависит, а от способа выборки. Ищи про равно предварительно собирая из флагов полное значение поля и все.
Ну тут ты отчасти прав, но там, где используются флаги, такие вещи обычно не прокатывают. Искать, как правило, нужно по определенному набору флагов, а не по всем, соответсвенно по "равно" тут ничего не повыбираешь. Кстати, если "равно" возможно, то и никакие флаги нафиг не нужны — получается просто разбиение всех данных на непересекающиеся классы.
VD>Короче, опиши саму задачу. Так будет проще дать разумный ответ.
Это точно.
Re[7]: Скорость выборки данных СУБД если много столбцов
Здравствуйте Lexey, Вы писали:
L>Здравствуйте VladD2, Вы писали:
ИВ>>>Н-да... Похоже, я несколько погорячился. Что хоть за база, на чем и под чем, может есть какое-то свое специфическое средство?
VD>>Да, главный вопрос: что за задача?
VD>>Уж больно предпосылки не для базы данных. (Пополнение раз в секунду и битовый массив вместо информации).
VD>>А насчет полного сканирования таблицы — так это не от данных зависит, а от способа выборки. Ищи про равно предварительно собирая из флагов полное значение поля и все.
L>Ну тут ты отчасти прав, но там, где используются флаги, такие вещи обычно не прокатывают. Искать, как правило, нужно по определенному набору флагов, а не по всем, соответсвенно по "равно" тут ничего не повыбираешь. Кстати, если "равно" возможно, то и никакие флаги нафиг не нужны — получается просто разбиение всех данных на непересекающиеся классы.
VD>>Короче, опиши саму задачу. Так будет проще дать разумный ответ.
L>Это точно.
Всем спасибо за помошь!!
Задача заключается в следующем. В базу данных примерно раз в секунду будут добляться записи. Записать сообщение в БД может любой модуль, а читателей сообщения может быть один, два — это должно быть записано в сообщении. После чтения сообщения данным модулем, он его должен пометить, что бы потом именно этот модуль второй раз его не выбрал. Причем если сообщение для двух модулей, должны быть соответсвенно две пометки — независимо для каждого модуля.
Желательно делать выборку из одной таблицы. СУБД ДОЛЖНА быть Informix — это не моя прихоть. (так надо)
Re[8]: Скорость выборки данных СУБД если много столбцов
Здравствуйте Манченко Сергей, Вы писали:
МС>Задача заключается в следующем. В базу данных примерно раз в секунду будут добляться записи. Записать сообщение в БД может любой модуль, а читателей сообщения может быть один, два — это должно быть записано в сообщении. После чтения сообщения данным модулем, он его должен пометить, что бы потом именно этот модуль второй раз его не выбрал. Причем если сообщение для двух модулей, должны быть соответсвенно две пометки — независимо для каждого модуля.
Значится так. Если у тебя таких модулей не сотни штук, то делать это лучше всего так:
Заводится таблица под сообщения и набор из N таблиц (по числу читающих модулей).
Само сообщение пишешь в таблицу сообщений, а его идентификатор и флаг прочитанности заносишь в таблицы для конкретных модулей. Каждый читатающий модуль будет работать на запись только со своей таблицей и на чтение с основной. Избыточность тут минимальна, нагрузка на сервер тоже. Единственное неудобство — плодить по таблице на читательский модуль, и процедура вставки слегка усложняется.
МС>Желательно делать выборку из одной таблицы. СУБД ДОЛЖНА быть Informix — это не моя прихоть. (так надо)
Не стоит такое делать на одной таблице, однозначно.
Re[9]: Скорость выборки данных СУБД если много столбцов
Спасибо огромное за совет. Скорее всего так и сделаем.
А гна счет неудобства — по таблице на модуль, я думаю это не страшно, тем более, что один раз создав таблицу для модуля, об можно "забыть", а таблицы можно именовать по уникальному идентификатору модуля.
L>Здравствуйте Манченко Сергей, Вы писали:
МС>>Задача заключается в следующем. В базу данных примерно раз в секунду будут добляться записи. Записать сообщение в БД может любой модуль, а читателей сообщения может быть один, два — это должно быть записано в сообщении. После чтения сообщения данным модулем, он его должен пометить, что бы потом именно этот модуль второй раз его не выбрал. Причем если сообщение для двух модулей, должны быть соответсвенно две пометки — независимо для каждого модуля.
L>Значится так. Если у тебя таких модулей не сотни штук, то делать это лучше всего так: L>Заводится таблица под сообщения и набор из N таблиц (по числу читающих модулей). L>Само сообщение пишешь в таблицу сообщений, а его идентификатор и флаг прочитанности заносишь в таблицы для конкретных модулей. Каждый читатающий модуль будет работать на запись только со своей таблицей и на чтение с основной. Избыточность тут минимальна, нагрузка на сервер тоже. Единственное неудобство — плодить по таблице на читательский модуль, и процедура вставки слегка усложняется.
МС>>Желательно делать выборку из одной таблицы. СУБД ДОЛЖНА быть Informix — это не моя прихоть. (так надо)
L>Не стоит такое делать на одной таблице, однозначно.
