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

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

ну а что делать со старой таблицей, там уже сами разберетесь

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

это наша сисадминская тема. кроме нас никто оттуда читать не будет. на время переливки можем подождать, полагаю

при этом в новой таблице вы можете сразу разобраться с партициями

при этом в новой таблице вы можете сразу разобраться с партициями

да, резонно

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

значит идею понял правильно. различие только в деталях реализации. спасибо большое

это сейчас выглядит более интересным вариантом.... удаление неделю или две наверное бы шло

какая бд сейчас лидирует в скорости по insert?

Текстовый файл

инсерт тоже может быть разным, одно дело инсертить 1 гуид в 1 таблицу, другое дело инсерт на лист А4

скорее на а4, но связей нет

скорее на а4, но связей нет

пробуйте cassandra\hbase, если потом не нужно так же читать в лист А4

читать нужно, но там скорость совсем не роляет, поэтому не критично

ну тогда вот 2 бд я назвал

clickhouse ещё можно глянуть

какая бд сейчас лидирует в скорости по insert?

myisam

монго

myisam

шо?

мускуль

Ребят, привет. Кто нибудь из вас знает про шаблон Model View? Это упрощенный MVC и содержит контроллер во view. Нужно просто инфы про него побольше а в инете худо как-то....

MVVM

Ребят, привет. Кто нибудь из вас знает про шаблон Model View? Это упрощенный MVC и содержит контроллер во view. Нужно просто инфы про него побольше а в инете худо как-то....

ну вообще из описания всё понятно, просто к базе из view обращаешься и вся бизнес логика у тебя во view, это сложно шаблоном назвать, скорее типичный говнокод уровня студента 1го курса

Ребят, привет. Кто нибудь из вас знает про шаблон Model View? Это упрощенный MVC и содержит контроллер во view. Нужно просто инфы про него побольше а в инете худо как-то....

Ёмаё, а БАЗЫ ДАННЫХ -то тут при чём?

model

имеет ли смысл существование первого индекса? isDefault 0 или 1, на одного userId не больше 15 строк будет { fields: ['userId', 'isDefault'], order: 'ASC' }, { fields: ['userId'], order: 'ASC' },

что значит первого?

а, допёрло...

из представленных

userId с isDefault = 1 естественно один

Ну очень сложно сказать. С одной стороны, да, покрывающий индекс может быть (селективности такое поле в индексе добавит мало). С другой стороны, вероятность использовать этот индекс как покрывающий, достаточно мала. Если ты имеешь в БД запросы под такой индекс, ну сделай его, хуже он не будет.

Я лично НЕ ВЕРЮ в покрывающие индексы, потому что запросов много обычно , и покрываются только , ну, скажем, 5ая часть в лучшем случае. Поле лишнее добавил — бац, уже не покрывается индексом.

селекты будут только при удалении userId с isDefault = 0

Также выгода от использования покрывающего индекса относительно мала. Поэтому я лично "не верю" в них, не учитываю их наличие при проектировании БД.

С другой стороны, у тебя могут быть запросы какие-то специфические, где эта малая толика, дающая покрытие, будет важна.

что значит покрывающий? в двух словах

имеет ли смысл существование первого индекса? isDefault 0 или 1, на одного userId не больше 15 строк будет { fields: ['userId', 'isDefault'], order: 'ASC' }, { fields: ['userId'], order: 'ASC' },

Первый индекс почти ничем не хуже второго, поэтому можно любой использовать

что значит покрывающий? в двух словах

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

Таким образом немного экономится IO

(очень немного обычно, но это зависит от плана запроса)

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

да

То есть по сути это такой индекс, который есть на все поля where?

Нет, все поля, нужные данному запросу из данной таблицы Они могут быть в любой части запроса , в любой фразе

А разве простая выборка ускоряется из индекса?

да

Смотря какая выборка и какой индекс

Ну я имею ввиду просто получение данных.

Смотря какой запрос.

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

Индекс же!=кеш

select * from theTable - например, никогда не будет ускоряться никаким индеком

А select col1 from t where id = 17

ну и если индекс соствавной ['userId', 'isDefault'], а ты ищешь по userId то работать он не будет

вроде

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

Кажется, вы друг друга стоите ?

разве?

А select col1 from t where id = 17

Индекс по айди есть. Индекс по col1 ничего не изменит же?

А select col1 from t where id = 17

Может ускорятся индексом по id

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

ну и если индекс соствавной ['userId', 'isDefault'], а ты ищешь по userId то работать он не будет

Будет. Всегда. 100% гарантия ( гарантия того, что он будет работать или не работать так же, как и несоставной индекс только по первому полю)

Индекс по айди есть. Индекс по col1 ничего не изменит же?

Нет, не изменит

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

и что ?

ERROR: S client not available

А ну вот. В начале просто неверно выразился не поля из where, а поля из любых условий.

и что ?

Ну по такому полю индекс не поможет, верно?

Может стоит пойти почитать за данную тему? Информации пруд пруди, с пояснениями, ситуациями, схемами.

А select col1 from t where id = 17

В контексте обсуждения покрывающих индексов если col1 есть в индексе с id , не важно, на каком месте (кроме ест. первого), то запрос может использовать только индекс, не выбирая при этом основную запись таблицы. А если добавить в запрос ещё и col2, он уже не сможет использовать только индекс.

Ну по такому полю индекс не поможет, верно?

Я уже сказал, что нет

Может стоит пойти почитать за данную тему? Информации пруд пруди, с пояснениями, ситуациями, схемами.

+100

Будет. Всегда. 100% гарантия ( гарантия того, что он будет работать или не работать так же, как и несоставной индекс только по первому полю)

работать то будет, но медленнее чем по одному полю, хотя бы потому что

сам индекс будет больше

Нет, там будут наносекунды разницы

я про ситуацию если индекс составной, а ищешь по одному полю из составного индекса

Он больше будет несильно, на 1 байт, и сравнение несильно медленнее. Так что разницы не будет практически

я про ситуацию если индекс составной, а ищешь по одному полю из составного индекса

я тоже про неё

1 байт на запись? :)

да

а если их миллион?

и чё? Ну , миллион. А 8 байт на ID тебя конечно не волнуют?

чёт сомневаюсь, надо будет почекать

Почекай

Почекай

а если там надо доставать файл(например чек) при запросе

Чего?

сам индекс будет больше

Это полный будет больше, а по первому полю почти такой

Чего?

Вы хоть пишите когода, подумать попытайтесь...

ы

что написали

В общем ладно, я домой...

кстати о файлах и прочих блобах, стоит ли вынести их в отдельную таблицу?

я админ а не кодер. ну вот возьмём ситуацию, есть информация гуиды, всякая инфа о фирме, и чек о продаже сам, есть 6 полей(фирма, дата продажи, ключ, сертификат,место продажи,продавец, и сам собственно чек) всё хранится в бд, и нужно составить запрос, который бы собрал всю инфу об продаже

кстати о файлах и прочих блобах, стоит ли вынести их в отдельную таблицу?

Зависит от СУБД

мускуль innodb

Как правило они и так хранятся физически отдельно