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

Ладно, почитаем про индексы

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

Возможно вы сделали не верный индекс и он не использовался.

Я вроде-бы тут кидал шпаргалку от рубцова

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

Я вроде-бы тут кидал шпаргалку от рубцова

А можете ещё раз сбросить?

Я сейчас в пути, не смогу,щас в файлах гляну

Хорошо

Я ещё книжку читаю MSSQL 2012. Основы T-SQL Ицик Бен-Ган

Я ещё книжку читаю MSSQL 2012. Основы T-SQL Ицик Бен-Ган

Методичку глянь

И прикинь - индексы правильно или не правильно юзал?

Тогда скорее всего неправильно

Так как смутно понял как их создать

Методичку глянь

Хорошо

Я вообще ГУИ юзаю

Мне визуально легче

А я привык код писать))

Что за гуя?

Что за гуя?

Ну я в mysql и юзаю phpmyadmin и mysql workbench

Ну я в mysql и юзаю phpmyadmin и mysql workbench

Dbeaver не пробовал?

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

Гыыы 24 миллиона строк... всего то...

Гыыы 24 миллиона строк... всего то...

select * into #f2_by_month from ( select 8 as F2_Month, * from FRESH_25_05_17_12PM.dbo.f2 (nolock) union all select 9 as F2_Month, * from FRESH_26_05_17_06AM.dbo.f2 (nolock) ) as f2 делаю так

это пока 2 базы

считалось 38 сек

а 12 баз о_О

это не рили пример, т. к. видно на какие числа базы, но просто привёл пример, что что-то я делаю не так

select * into #f2_by_month from ( select 8 as F2_Month, * from FRESH_25_05_17_12PM.dbo.f2 (nolock) union all select 9 as F2_Month, * from FRESH_26_05_17_06AM.dbo.f2 (nolock) ) as f2 делаю так

мне это вообще ни о чем. я в SQL дуб. но 24 миллиона строк это фигня

Dbeaver не пробовал?

Нет

считалось 38 сек

Эксплэйн сделай, посмотри чего происходит под капотом

а как его сделать?

а как его сделать?

Гугли "sql explain"

ок, спасибо

что вы там, опять ts в реляционку запихиваете?

что вы там, опять ts в реляционку запихиваете?

это ж цель всей жизни, натянуть сову на глобус

Всем привет! Есть Две таблицы Albums и Photos. Нужно добавить фичу "комментарии" к каждой из них. Сперва подумал что создам одну таблицу comments и буду туда записывать комментарии в общак. Но тут вопрос внешний ключ то один. Выходит для каждой таблицы нужно создать по отдельной таблице с комментариями >> albums_comments и photos_comments ? Правильно или есть другие решения ?

Народ, такой вопросец. Насколько вообще работающий вариант с переносом бд целиком? Не через mysqldump какой-нибудь, а перекинуть lamp сборку вместе с файлами бд?

Всем привет! Есть Две таблицы Albums и Photos. Нужно добавить фичу "комментарии" к каждой из них. Сперва подумал что создам одну таблицу comments и буду туда записывать комментарии в общак. Но тут вопрос внешний ключ то один. Выходит для каждой таблицы нужно создать по отдельной таблице с комментариями >> albums_comments и photos_comments ? Правильно или есть другие решения ?

Да вроде всё верно думаете.

Тобиж для каждой сущьности сделать свою таблицу с комментариями ?

Да вроде всё верно думаете.

Тобиж для каждой сущьности сделать свою таблицу с комментариями ?

Ну да, только если вы не хотите, чтобы в обоих таблицах были одни и те же комменты.

Спасибо за валидацию идеи))

можно и в одну таблицу, ничего же не мешает сделать 2 ключа

можно и в одну таблицу, ничего же не мешает сделать 2 ключа

тогда 2 поля для внешних ключей будет в comments, верно?

защем?

нет? а как тогда?

пардон

пора домой, заработался)

:DDD

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

Спасибо за валидацию идеи))

Можно и в одну таблицу всё фигачить... В общем, смотри как тебе проще.

Спасибо, в этом случае буду фигачит по разным таблицам

пора домой, заработался)

выхи же))

у кого-то выхи, а у кого-то день рабочий

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

:D

а ничего не поделаешь ))

кого ебёт чужое горе)

и то верно ))

Чет поддастали меня эти графовые дб. В связи с чем вопрос. Если сделать таблицу из 5 столбцов. В каждом столбце будет хранится один long. То выдержит ли тот же postgre десяток миллиардов строк в такой таблице и как толго будет делать с нее селект? У кого нибуть есть опыт с таким обьемом?

Всем привет! Есть Две таблицы Albums и Photos. Нужно добавить фичу "комментарии" к каждой из них. Сперва подумал что создам одну таблицу comments и буду туда записывать комментарии в общак. Но тут вопрос внешний ключ то один. Выходит для каждой таблицы нужно создать по отдельной таблице с комментариями >> albums_comments и photos_comments ? Правильно или есть другие решения ?

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

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

Я тоже думаю с отдельными таблицами будет проще) Спасибо!

ERROR: S client not available

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

Комменты вордовских файлов ))

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

Тут скорее важность, а надо ли эти каменты совмещать, и если надо, то лучше по типу. А если нет, то лучше отдельно

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

Чет поддастали меня эти графовые дб. В связи с чем вопрос. Если сделать таблицу из 5 столбцов. В каждом столбце будет хранится один long. То выдержит ли тот же postgre десяток миллиардов строк в такой таблице и как толго будет делать с нее селект? У кого нибуть есть опыт с таким обьемом?

а чего нет? правда база в тыкву превратится :)

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

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

Все. :(

да у вас хайлоад, молодой человек

У меня попытка проводить обобщения над большим количеством множеств

какая-то аналитическая система?

За молодого спасиб конечно. Прям лет 20 скинул

какая-то аналитическая система?

Типа того. Есть просто одна модель которую очень хочется проверить на практике.

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

И чем дальше в лес тем толще логи

Потому думаю над классикой в таблицах

мне идея лесов и других древовидных структур внутри реляционок никогда не нравилась

Множество это не лес и дерево

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

в mysql точно ничего нет по множествам нормального)

Вопрос состоит если у меня есть скажем 10 миллионов точек каждая может принадлежать до 20 тысячам множеств. Как это все акуратно сложить с таблицы и при этом что бы был довольно быстрый доступ. Согласен даже на пару минут

Что иметь возможность по группе точек вытащить множества где эти точки есть

Чет поддастали меня эти графовые дб. В связи с чем вопрос. Если сделать таблицу из 5 столбцов. В каждом столбце будет хранится один long. То выдержит ли тот же postgre десяток миллиардов строк в такой таблице и как толго будет делать с нее селект? У кого нибуть есть опыт с таким обьемом?

Колонучную БД лучше взять

Колонучную БД лучше взять

Эт какая?

Вертика, кликхаус

Вертика, кликхаус

Записал почитаю

Вертика с таким объем на фри наверно зайдет, хотя надо точнее смотреть, у них всего 1 терабайт на коммьюнити

а кликъхаус опенсорс вроде?

а кликъхаус опенсорс вроде?

Да

Вертика с таким объем на фри наверно зайдет, хотя надо точнее смотреть, у них всего 1 терабайт на коммьюнити

У меня в сервере нет терабайта ни дисков ни оперативки. По расчетам все должно уместится в 100 гигов. Этого должно хватить для проверки

У меня сейчас 100 гигов на вертики в проде крутится, отличный полет. А если есть опыт постгре, то многое уже будет знакомо