он кстати теперь с какого-то хуя забанен сами понимаете кем

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

Всем привет

товарищи есть кто работал с Oracle 12cR2 на IBM AIX?

https://www.coursera.org/learn/data-bases-intr/

просто оставлю это здесь

норм, чо

можно даж запинить )))

народ, подскажите, для того что бы промежуточная таблица в связи many-to-many стала таблицей связи надо в ней один из внешних ключей объявить primary key?

а типа без PK она таблицей связи быть перестанет?

что за бред...

то есть таблица связи может быть вообще без PK ?

у тебя связь many to many осуществляется через FK обоих таблиц в промежуточной таблице, PK тут ни при чем, но лучше чтобы он был и был суррогатный

народ, подскажите, для того что бы промежуточная таблица в связи many-to-many стала таблицей связи надо в ней один из внешних ключей объявить primary key?

Нет, вовсе не обязательно.

то есть таблица связи может быть вообще без PK ?

Любая таблица не может быть без PK

может

чисто технически может быть что угодно

может

обычно если явного PK нет - сторадж создаёт внутренний, который по сути rowid

обычно, но тут фраза "не может быть без РК" она несовсем верна

обычно, но тут фраза "не может быть без РК" она несовсем верна

как ты на low level будешь идентифицировать запись?

должна быть уникальная сущность в любом случае

так что не может

обычно если явного PK нет - сторадж создаёт внутренний, который по сути rowid

Парни, (и девчата), технически может всё. Но БД не может работать с таблицей без PK.

вот так, да, такая фраза она лучше

спасибо

она понятнее, что ли

Коллеги, подскажите кто нибудь использует в работе секционирование? Секционирование таблиц дает существенную прибавку к производительности?

речь про MS SQL

зависит от множества факторов

От сценария зависит

но в целом да, дает прибавку, иногда даже может дать существенную

Секционирование должно быть учтено при разработке приложения

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

как правильно делать секционирование? Я создал несколько файловых групп+несколько файлов к ним, потом через мастер секционирования прогнал таблицу и всё, что то еще нужно сделать? Я все правльно сделал?

как правильно делать секционирование? Я создал несколько файловых групп+несколько файлов к ним, потом через мастер секционирования прогнал таблицу и всё, что то еще нужно сделать? Я все правльно сделал?

Попробуем с начала. зачем?

есть визард? ?

есть визард? ?

Ты погоди. А то сейчас выясним что там по 25 строк что бы юзерам удобнее смотреть.

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

делай партиции по дате

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

Может начать с запроса?

есть визард? ?

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

И что значит очень большое время?

я бы начал с инструмента

Может начать с запроса?

с ним все норм

с ним все норм

Смелое утверждение

хз, как там визард работает в MS SQL

партиции всегда руками пилил

Выборка списка по дате занимает большое время. И с запросом все нормально.

Коллеги, вопрос только в том, правильно ли я секционирую

это нужно делать в ручную или через визад?

файл с секциями нужно убирать с того диска на котором находится файл с актуальной инфой?

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

?

Коллеги, вопрос только в том, правильно ли я секционирую

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

как это делаете вы?

создание групп и файлов опускаем

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

везде написано, что секционирование дает прирост, но за счет чего??

везде написано, что секционирование дает прирост, но за счет чего??

За счет секционирования? Ваш кэп

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

)

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

и тогда, если в where, укзаны параметры не подразумевающие использование секции со "старыми" данными - будет прирост

а если в where написать что-то, вызывающее seek по обоим (всем) секциям - прироста не будет

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

а там оптимизатор сам не понимает что ты лезешь в конкретную партицию(и)?

ERROR: S client not available

полагаю, так и есть

а там оптимизатор сам не понимает что ты лезешь в конкретную партицию(и)?

выше сообщением написал

вернее будет, но не более чем от обычного разделения на файловые группы

а там оптимизатор сам не понимает что ты лезешь в конкретную партицию(и)?

Эт в муське?

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

Эт в муське?

yep

yep

Фантастика же.

Эт в муське?

при условном where = '2018-07-20' и секционировании по датам, он будет смотреть в партицию содержащую эту дату без явного её указания в условии.

при условном where = '2018-07-20' и секционировании по датам, он будет смотреть в партицию содержащую эту дату без явного её указания в условии.

это само собой

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

при условном where = '2018-07-20' и секционировании по датам, он будет смотреть в партицию содержащую эту дату без явного её указания в условии.

но если ты укажешь в where чтото чему потребуется seek по всем секциям - получишь потерю производительности (в случае, если другая партиция на медленном диске)

Коллеги, подскажите кто нибудь использует в работе секционирование? Секционирование таблиц дает существенную прибавку к производительности?

Конечно, оно даёт прирост, проблема только, что не всегда (не для всех запросов), и каков размер этого прироста. В частности, если запросу нужны все данные, из всех секций, то будет наоборот замедление выполнения примерно во столько раз, сколько секций (но обработка одной секции естественно будет наоборот снижаться относительно варианта одной консолидированной таблицы) Ну и чтобы запросы, которые используют отсечение секций, почувствовали разницу в производительности, секций должно быть много. Хотя бы 10. А лучше 100-1000.

как правильно делать секционирование? Я создал несколько файловых групп+несколько файлов к ним, потом через мастер секционирования прогнал таблицу и всё, что то еще нужно сделать? Я все правльно сделал?

Это надо обсуждать только в контексте твоей конкретной задачи. Абстрактно -- бессмысленно

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

А сколько там записей?

файл с секциями нужно убирать с того диска на котором находится файл с актуальной инфой?

Можно, но вовсе не обязательно.

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

Нет. Прав только отчасти

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

Если такая возможность есть, разноси. Если нет, или это будет сложно, можно не разносить.

везде написано, что секционирование дает прирост, но за счет чего??

За счёт уменьшения количества записей в одной "таблице" с которой СУБД имеет дело. Именно поэтому надо иметь большое число секций, иначе ускорение будет мизерным.

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

Не, ты неправ. Можно унести , можно не уносить, ускорение всё равно будет.

а там оптимизатор сам не понимает что ты лезешь в конкретную партицию(и)?

Понимает.

Не, ты неправ. Можно унести , можно не уносить, ускорение всё равно будет.

в случае чтения одной секции - да

в случае чтения нескольких - нет

в случае чтения нескольких - нет

это специфика mssql?

в случае чтения нескольких - нет

Ну я запутался.

это специфика mssql?

Да нет, это более-менее везде одинаково

вернее не так. усокрения в прям в разы - не будет точно.

вообще какие проблемы то. возьмите замерьте, потом распилите и замерьте заново

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

вернее не так. усокрения в прям в разы - не будет точно.

Ну вот в том и дело, что чтобы вообще какое-то ускорение почуствовать, оно в БД должно быть ХОТЯ БЫ НА ПОРЯДОК. (в 10 раз).