Этого треда уже нет.
Это копия, сохраненная 31 января 2020 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 31 января 2020 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
17 Кб, 374x474А вот и новый оптимизированный баз данных тред,
в котором мы
-Выслушиваем, почему в шапке по-прежнему отсутствует инфа для вкативания
-Разбираемся, почему PostgreSQL - не Oracle
-Пытаемся понять, зачем нужен Тырпрайс, если есть бесплатный опенсурс
-Обсуждаем, какие новые тенденции хранения данных появляются в современном цифровом обещстве
-Решаем всем тредом лабы для заплутавших студентов и задачки с sql-ex для тех, у кого завтра ПЕРВОЕ собеседование
-Анализируем, как работает поиск вконтакте
-Игнорируем конкаренси-шизика, не понимающего, зачем базы данных нужны
-И просто хорошо проводим время, обсирая чужой код, не раскрывая, как писать правильно
Поехали!
в котором мы
-Выслушиваем, почему в шапке по-прежнему отсутствует инфа для вкативания
-Разбираемся, почему PostgreSQL - не Oracle
-Пытаемся понять, зачем нужен Тырпрайс, если есть бесплатный опенсурс
-Обсуждаем, какие новые тенденции хранения данных появляются в современном цифровом обещстве
-Решаем всем тредом лабы для заплутавших студентов и задачки с sql-ex для тех, у кого завтра ПЕРВОЕ собеседование
-Анализируем, как работает поиск вконтакте
-Игнорируем конкаренси-шизика, не понимающего, зачем базы данных нужны
-И просто хорошо проводим время, обсирая чужой код, не раскрывая, как писать правильно
Поехали!
Кароч, народ, хелп.
надо вспомнить курс бд и задрочить скл до среднего уровня, тихонько восседая в техподе. Нужна ультрагоднота: посоветуйте 1 книгу и 1 онлайн-ресурс для решения задачек. С меня нихуя.
надо вспомнить курс бд и задрочить скл до среднего уровня, тихонько восседая в техподе. Нужна ультрагоднота: посоветуйте 1 книгу и 1 онлайн-ресурс для решения задачек. С меня нихуя.
>>02880
Кстати
Консенсуса еще нет?
Ну, кроме того, что постгрес бесплатнее.
Кстати
>-Разбираемся, почему PostgreSQL - не Oracle
Консенсуса еще нет?
Ну, кроме того, что постгрес бесплатнее.
>>02880
Есть даже доступ к адски медленной тестовой бд на oracle
Есть даже доступ к адски медленной тестовой бд на oracle
>>02870 (OP)
Анонасы!
Я старый пердун, который 20 хуярит на РДБМсах всех сортов.
Поскольку я старый пердун, мне тяжело для поиска информации пользоваться модными стильными молодежными сайтами-простынями, поэтому спрошу здесь:
В чем каеф от noSQL баз?
Где их уместно применить, и почему?
Про key-value мне можно не пояснять, тут все понятно.
Про "азазаза можно не учить сложный sql и можно не думать о структуре данных" тоже можно не пояснять.
Даже агитки про репликацию и кластеризацию можно не повтрять.
Мне интересна польза noSQL именно с точки зрения задач по обработке и хранению данных.
Что это за задачи такие?
Там, где мне насрать на какую-либо вменяемую структуру данных?
Там, где мне насрать на целостность?
Там, где мне насрать на гибкость и скорость выборки?
Там, где мне насрать на возможность развития системы в части схемы данных?
Я без подъебки спрашиваю, мне правдо интересно.
Анонасы!
Я старый пердун, который 20 хуярит на РДБМсах всех сортов.
Поскольку я старый пердун, мне тяжело для поиска информации пользоваться модными стильными молодежными сайтами-простынями, поэтому спрошу здесь:
В чем каеф от noSQL баз?
Где их уместно применить, и почему?
Про key-value мне можно не пояснять, тут все понятно.
Про "азазаза можно не учить сложный sql и можно не думать о структуре данных" тоже можно не пояснять.
Даже агитки про репликацию и кластеризацию можно не повтрять.
Мне интересна польза noSQL именно с точки зрения задач по обработке и хранению данных.
Что это за задачи такие?
Там, где мне насрать на какую-либо вменяемую структуру данных?
Там, где мне насрать на целостность?
Там, где мне насрать на гибкость и скорость выборки?
Там, где мне насрать на возможность развития системы в части схемы данных?
Я без подъебки спрашиваю, мне правдо интересно.
>>02881
Боюсь, что консенсуса нет, так как большинство юзает просто то, что первое им под руку попалось.
На работе MySQL? Значит, MySQL топ за свои деньги.
Боюсь, что консенсуса нет, так как большинство юзает просто то, что первое им под руку попалось.
На работе MySQL? Значит, MySQL топ за свои деньги.
>>02886
Так вот, как раз, скорость выборки будет выше, когда ты просто объект по ключу забираешь.
Так вот, как раз, скорость выборки будет выше, когда ты просто объект по ключу забираешь.
>>03003
"выбрать всех пидарасов по фамилии Петров"
Как там у тебя в монгодб будет со скоростью такой выборки?
По какому ключу ты там что будешь забирать?
"выбрать всех пидарасов по фамилии Петров"
Как там у тебя в монгодб будет со скоростью такой выборки?
По какому ключу ты там что будешь забирать?
>>02903
понятия не имею про "1 книгу"
Почему вообще ты ограничиваешься 1-й?
https://www.geeksforgeeks.org/sql-tutorial/
и
http://www.sql-ex.ru/
Последний сделан людьми, которые не умеют в человеческий язык, поэтому там не всегда можно понять, чего они от тебя хотят.
Ну, тоже привыкай.
Но нет способа лучше, чем сделать какую-нибудь систему самому.
Придумай, набросай схему БД.
Напиши скрипт для ее генерации.
Напиши CRUDы для нужных тебе операций.
Ну и селекты.
Потом прикинь, какие бы ты хотел отчеты получить от такой системы. Вот тебе еще десяток хитровыебанных запросов.
понятия не имею про "1 книгу"
Почему вообще ты ограничиваешься 1-й?
https://www.geeksforgeeks.org/sql-tutorial/
и
http://www.sql-ex.ru/
Последний сделан людьми, которые не умеют в человеческий язык, поэтому там не всегда можно понять, чего они от тебя хотят.
Ну, тоже привыкай.
Но нет способа лучше, чем сделать какую-нибудь систему самому.
Придумай, набросай схему БД.
Напиши скрипт для ее генерации.
Напиши CRUDы для нужных тебе операций.
Ну и селекты.
Потом прикинь, какие бы ты хотел отчеты получить от такой системы. Вот тебе еще десяток хитровыебанных запросов.
>>02934
Но мне интереснее обсудить этот вопрос с теми, ктро работал и с Ораклом, и с Мускл.
Мнение вчерашних школьников, натягивающих пхп-морду на очередной магазин сушеного навоза, сам понимаешь, стоит недорого.
Но мне интереснее обсудить этот вопрос с теми, ктро работал и с Ораклом, и с Мускл.
Мнение вчерашних школьников, натягивающих пхп-морду на очередной магазин сушеного навоза, сам понимаешь, стоит недорого.
>>03463
Спасибо за ответ.
Спасибо за ответ.
>>02870 (OP)
Вы дауны, можно все в текстовых файликах хранить.
Вы дауны, можно все в текстовых файликах хранить.
>>03460
Ты просто, видимо, не понимаешь, зачем нужны объектные БД.
Они не нужны для "where ... like ..."
Они нужны для того, чтобы быстро доставать объекты в уже подготовленной форме.
Например, достаешь ты юзера "a.petrov", а у него куча говна в виде документов, докторских степеней, дипломов и сертификатов.
Если бы ты работал с реляционной бд, ты бы писал несколько запросов
select
id, name
from user
where user_login = 'a.petrov'
select
from dociments
where user_id = ...
select
from sertificates
where user_id = ...
и .п.
А с объектной бд ты просто достанешь юзера и все, что к нему относится, сразу.
{
id: 1,
login: "a.petrov",
certificates: [ ... ].
documents: [ ... ]
}
Ты просто, видимо, не понимаешь, зачем нужны объектные БД.
Они не нужны для "where ... like ..."
Они нужны для того, чтобы быстро доставать объекты в уже подготовленной форме.
Например, достаешь ты юзера "a.petrov", а у него куча говна в виде документов, докторских степеней, дипломов и сертификатов.
Если бы ты работал с реляционной бд, ты бы писал несколько запросов
select
id, name
from user
where user_login = 'a.petrov'
select
from dociments
where user_id = ...
select
from sertificates
where user_id = ...
и .п.
А с объектной бд ты просто достанешь юзера и все, что к нему относится, сразу.
{
id: 1,
login: "a.petrov",
certificates: [ ... ].
documents: [ ... ]
}
>>03460
Ты просто, видимо, не понимаешь, зачем нужны объектные БД.
Они не нужны для "where ... like ..."
Они нужны для того, чтобы быстро доставать объекты в уже подготовленной форме.
Например, достаешь ты юзера "a.petrov", а у него куча говна в виде документов, докторских степеней, дипломов и сертификатов.
Если бы ты работал с реляционной бд, ты бы писал несколько запросов
select
id, name
from user
where user_login = 'a.petrov'
select
from dociments
where user_id = ...
select
from sertificates
where user_id = ...
и .п.
А с объектной бд ты просто достанешь юзера и все, что к нему относится, сразу.
{
id: 1,
login: "a.petrov",
certificates: [ ... ].
documents: [ ... ]
}
Ты просто, видимо, не понимаешь, зачем нужны объектные БД.
Они не нужны для "where ... like ..."
Они нужны для того, чтобы быстро доставать объекты в уже подготовленной форме.
Например, достаешь ты юзера "a.petrov", а у него куча говна в виде документов, докторских степеней, дипломов и сертификатов.
Если бы ты работал с реляционной бд, ты бы писал несколько запросов
select
id, name
from user
where user_login = 'a.petrov'
select
from dociments
where user_id = ...
select
from sertificates
where user_id = ...
и .п.
А с объектной бд ты просто достанешь юзера и все, что к нему относится, сразу.
{
id: 1,
login: "a.petrov",
certificates: [ ... ].
documents: [ ... ]
}
>>03718
какой формат файлика будешь использовать?
что будешь делать, когда несколько людей одновременно будут хотеть записать что-нибудь в файлик?
какой формат файлика будешь использовать?
что будешь делать, когда несколько людей одновременно будут хотеть записать что-нибудь в файлик?
>>03872
Приглашаю тебя еще раз перечесть мой исходный пост.
В частности, там написано:
Также, там написано:
Твой пример, похоже, дает утвердительный ответ на этот вопрос.
Но я не понимаю смысла.
Как часто тебе нужно ВСЕ брать неделимым куском, из которого хуй что вытащишь без последующей обработки?
Как частно надо хранить все единым кускому, в который не вставишь просто так какой-то кусочек, не заебавшись сперва все разбирать, а потом пересобирать?
Если что, то всякие materialized view и витрины всех сортов есть и в реляционных базах. Как раз, чтобы держать "объекты в подготовленной форме", которые не особо оперативно меняются. При этом, благодаря дроблению на куски и языку запросов, эти "объекты в подготовленной форме" можно-таки удобно подбирать и искать.
Объекты в подготовленном виде вообще не требуют базы данных. Это файловая система. Тебе для выбора нужна только ссылка на нужное место. "Вот этом месте лежит куча говна про a.petrov".
Ну, это в моем понимании.
Вот я и пытаюсь разобраться, в чем дефекты моего понимания.
Пока безуспешно.
>Ты просто, видимо, не понимаешь, зачем нужны объектные БД.
Приглашаю тебя еще раз перечесть мой исходный пост.
В частности, там написано:
>В чем каеф от noSQL баз?
>Где их уместно применить, и почему?
Также, там написано:
>Там, где мне насрать на гибкость и скорость выборки?
Твой пример, похоже, дает утвердительный ответ на этот вопрос.
Но я не понимаю смысла.
Как часто тебе нужно ВСЕ брать неделимым куском, из которого хуй что вытащишь без последующей обработки?
Как частно надо хранить все единым кускому, в который не вставишь просто так какой-то кусочек, не заебавшись сперва все разбирать, а потом пересобирать?
Если что, то всякие materialized view и витрины всех сортов есть и в реляционных базах. Как раз, чтобы держать "объекты в подготовленной форме", которые не особо оперативно меняются. При этом, благодаря дроблению на куски и языку запросов, эти "объекты в подготовленной форме" можно-таки удобно подбирать и искать.
Объекты в подготовленном виде вообще не требуют базы данных. Это файловая система. Тебе для выбора нужна только ссылка на нужное место. "Вот этом месте лежит куча говна про a.petrov".
Ну, это в моем понимании.
Вот я и пытаюсь разобраться, в чем дефекты моего понимания.
Пока безуспешно.
Где курить про оптимизацию и йоба-техники?
Читал как-то, что ForeignKey тру-батьки не пользуются пушо тормозит чтение и запись, насколько правда?
Читал как-то, что ForeignKey тру-батьки не пользуются пушо тормозит чтение и запись, насколько правда?
>>02870 (OP)
я может конечно что то недопонимаю, может так быстрее, может это просто рофл. НО ЧТО ЭТО БЛЯДЬ ЗА ХУЙНЯ?
Бтв, раз уж это скл тред, самое время спросить пару вопрос:
Как проще всего получить 3 последних поста, привязанных к thread по полю parent, при этом еще получить сам тред и его пост, который я достал относительно поля post_id в треде, то есть итог : (Thread, Post, [3; Post]), используетсч лишь две страницы, чекал вакабу, тайниб, везде на каждый тред делается еще один запрос к дб, то есть на один запрос юзера получить все треды в борде, будет выполнено 101 запросов в дб, есть варианты как сделать лучше? ну кроме уж очивидного wherein
Стоит ли хранить количество ответов в треде в виде поля replies_count, или все же count(*) from posts where... лучше?
>отдельная таблица для юзеров
я может конечно что то недопонимаю, может так быстрее, может это просто рофл. НО ЧТО ЭТО БЛЯДЬ ЗА ХУЙНЯ?
Бтв, раз уж это скл тред, самое время спросить пару вопрос:
Как проще всего получить 3 последних поста, привязанных к thread по полю parent, при этом еще получить сам тред и его пост, который я достал относительно поля post_id в треде, то есть итог : (Thread, Post, [3; Post]), используетсч лишь две страницы, чекал вакабу, тайниб, везде на каждый тред делается еще один запрос к дб, то есть на один запрос юзера получить все треды в борде, будет выполнено 101 запросов в дб, есть варианты как сделать лучше? ну кроме уж очивидного wherein
Стоит ли хранить количество ответов в треде в виде поля replies_count, или все же count(*) from posts where... лучше?
55 Кб, 540x757Уважаемые пиздюки, меня заебали разрабы. Наша компания предоставляет разрабам виртуальный сервер (CPU 4 ядра, ОЗУ 16 Гб, виртуальное дисковое пространство 2 Тб), они там варят БД какой-то информ. системы. Постоянно жалуются на высокий iowait. Он у них и правда есть 80% (highrst latency диска 25 млсек). Думают, что проблема в диске (виртуальный же), но наверняка это их хуевые БД являются узким местом. Подскажите как диагностировать проблему, а именно, что виновато: диск или их БД на Постгресе)
пик_рандом
пик_рандом
>>04513
Просто запустить минипрограмму которая будет читать из файлов и писать в файлы, засечь сколько ей нужно времни и потом сделать то же самое через програму разрабов. Думаю проблема в разрабах, так как ты себе даже не представляешь что за дауны работают в компаниях. Но не в бд. Отпидарашеная бд довольно быстро всё делает, по 0.002 секунды на операцию. Проблема в кривожопости самих разрабов и их мусорной проги.
Просто запустить минипрограмму которая будет читать из файлов и писать в файлы, засечь сколько ей нужно времни и потом сделать то же самое через програму разрабов. Думаю проблема в разрабах, так как ты себе даже не представляешь что за дауны работают в компаниях. Но не в бд. Отпидарашеная бд довольно быстро всё делает, по 0.002 секунды на операцию. Проблема в кривожопости самих разрабов и их мусорной проги.
>>04546
Спасибо за ответ, братишка. Доступ к их серверу у меня ограниченный (там какой-то всратый русский дистр на основе Дебиана и они мне выделили порезанную учётку) + есть ещё средства мониторинга и анализа VMWare. Ну ладно, буду думать что да как.
Спасибо за ответ, братишка. Доступ к их серверу у меня ограниченный (там какой-то всратый русский дистр на основе Дебиана и они мне выделили порезанную учётку) + есть ещё средства мониторинга и анализа VMWare. Ну ладно, буду думать что да как.
>>04677
Муська
Муська
и тред незамедлительно скатился в говно
>>04431
Напиши структуру таблиц и входные параметры, по которым ты искать хочешь. Ни ухуя не понятно же.
>>04513
Кажется, что проблема в виртуалке. Плюс непонятно, что за диски.
Здорово, если под БД выделяется SSD, тогда все быстро работает.
>>03920
ForeignKey, конечно, замедляет, инсерт и делит, потому что перед инсертом прозводится необходимая проверка на наличие такого ключа в таблице, на которую ссылается вставляемая запись. При удалении аналогично - хочшеь удалить запись из справочника - а нельзя, ведь на него ссылаются миллиард строк в тысячи таблицах.
ForeignKey, Действительно, не всегда используют, потому что он еще и усложняет саму разработку, требуя производить каскадное удаление записей, например.
Например, при разработке хранилища данных не принято использовать Foreign key, чтобы не усложнять и без того тяжелые инсерты.
Но стоит помнить, что, чем меньше у тебя связей между таблицами, тем менее целостной будет твоя система.
>>03910
Что тут непонятного?
Есть у тебя юзер, у него есть сертификаты и, скажем, ученые степени, всё в разных таблицах лежит. Вот ты будешь либо писать 3 запроса, чтобы достать юзера, сертификаты и степени, либо все будешь доставать в одном, используя джойны.
А в противовес этому у тебя есть просто объект "Юзер", с кучей атрибутов-массивов, который ты достаешь одним запросом. Это будет работать однозначно быстрее.
Я вообще не уверен, что есть какие-то дауны, которые считают, что надо только объектные БД использовать, патаму что удобнее. Просто в некоторых случаях удобно взять объект по ключу, который когда-то ты сохранил, тем более, что это будет быстрее. Эта скорость можно не замечать, когда у тебя 20 юзеров. Однако, если у тебя 20000000 юзеров, то тут каждая наносекунда может оказаться решающей.
А в каких-то случаях удобно использовать реляционку, потому что там все твёрдо и четко. Никто комбинированные подходы не отменял.
Например, юзаешь ты google firebase, как объектную БД, на фронте, а для автоматизации основных процессов компании юзаешь SQL Server на бэк-е с констрейнтами и прочими блэкджеками.
Напиши структуру таблиц и входные параметры, по которым ты искать хочешь. Ни ухуя не понятно же.
>>04513
Кажется, что проблема в виртуалке. Плюс непонятно, что за диски.
Здорово, если под БД выделяется SSD, тогда все быстро работает.
>>03920
ForeignKey, конечно, замедляет, инсерт и делит, потому что перед инсертом прозводится необходимая проверка на наличие такого ключа в таблице, на которую ссылается вставляемая запись. При удалении аналогично - хочшеь удалить запись из справочника - а нельзя, ведь на него ссылаются миллиард строк в тысячи таблицах.
ForeignKey, Действительно, не всегда используют, потому что он еще и усложняет саму разработку, требуя производить каскадное удаление записей, например.
Например, при разработке хранилища данных не принято использовать Foreign key, чтобы не усложнять и без того тяжелые инсерты.
Но стоит помнить, что, чем меньше у тебя связей между таблицами, тем менее целостной будет твоя система.
>>03910
Что тут непонятного?
Есть у тебя юзер, у него есть сертификаты и, скажем, ученые степени, всё в разных таблицах лежит. Вот ты будешь либо писать 3 запроса, чтобы достать юзера, сертификаты и степени, либо все будешь доставать в одном, используя джойны.
А в противовес этому у тебя есть просто объект "Юзер", с кучей атрибутов-массивов, который ты достаешь одним запросом. Это будет работать однозначно быстрее.
Я вообще не уверен, что есть какие-то дауны, которые считают, что надо только объектные БД использовать, патаму что удобнее. Просто в некоторых случаях удобно взять объект по ключу, который когда-то ты сохранил, тем более, что это будет быстрее. Эта скорость можно не замечать, когда у тебя 20 юзеров. Однако, если у тебя 20000000 юзеров, то тут каждая наносекунда может оказаться решающей.
А в каких-то случаях удобно использовать реляционку, потому что там все твёрдо и четко. Никто комбинированные подходы не отменял.
Например, юзаешь ты google firebase, как объектную БД, на фронте, а для автоматизации основных процессов компании юзаешь SQL Server на бэк-е с констрейнтами и прочими блэкджеками.
>>04431
Напиши структуру таблиц и входные параметры, по которым ты искать хочешь. Ни ухуя не понятно же.
>>04513
Кажется, что проблема в виртуалке. Плюс непонятно, что за диски.
Здорово, если под БД выделяется SSD, тогда все быстро работает.
>>03920
ForeignKey, конечно, замедляет, инсерт и делит, потому что перед инсертом прозводится необходимая проверка на наличие такого ключа в таблице, на которую ссылается вставляемая запись. При удалении аналогично - хочшеь удалить запись из справочника - а нельзя, ведь на него ссылаются миллиард строк в тысячи таблицах.
ForeignKey, Действительно, не всегда используют, потому что он еще и усложняет саму разработку, требуя производить каскадное удаление записей, например.
Например, при разработке хранилища данных не принято использовать Foreign key, чтобы не усложнять и без того тяжелые инсерты.
Но стоит помнить, что, чем меньше у тебя связей между таблицами, тем менее целостной будет твоя система.
>>03910
Что тут непонятного?
Есть у тебя юзер, у него есть сертификаты и, скажем, ученые степени, всё в разных таблицах лежит. Вот ты будешь либо писать 3 запроса, чтобы достать юзера, сертификаты и степени, либо все будешь доставать в одном, используя джойны.
А в противовес этому у тебя есть просто объект "Юзер", с кучей атрибутов-массивов, который ты достаешь одним запросом. Это будет работать однозначно быстрее.
Я вообще не уверен, что есть какие-то дауны, которые считают, что надо только объектные БД использовать, патаму что удобнее. Просто в некоторых случаях удобно взять объект по ключу, который когда-то ты сохранил, тем более, что это будет быстрее. Эта скорость можно не замечать, когда у тебя 20 юзеров. Однако, если у тебя 20000000 юзеров, то тут каждая наносекунда может оказаться решающей.
А в каких-то случаях удобно использовать реляционку, потому что там все твёрдо и четко. Никто комбинированные подходы не отменял.
Например, юзаешь ты google firebase, как объектную БД, на фронте, а для автоматизации основных процессов компании юзаешь SQL Server на бэк-е с констрейнтами и прочими блэкджеками.
Напиши структуру таблиц и входные параметры, по которым ты искать хочешь. Ни ухуя не понятно же.
>>04513
Кажется, что проблема в виртуалке. Плюс непонятно, что за диски.
Здорово, если под БД выделяется SSD, тогда все быстро работает.
>>03920
ForeignKey, конечно, замедляет, инсерт и делит, потому что перед инсертом прозводится необходимая проверка на наличие такого ключа в таблице, на которую ссылается вставляемая запись. При удалении аналогично - хочшеь удалить запись из справочника - а нельзя, ведь на него ссылаются миллиард строк в тысячи таблицах.
ForeignKey, Действительно, не всегда используют, потому что он еще и усложняет саму разработку, требуя производить каскадное удаление записей, например.
Например, при разработке хранилища данных не принято использовать Foreign key, чтобы не усложнять и без того тяжелые инсерты.
Но стоит помнить, что, чем меньше у тебя связей между таблицами, тем менее целостной будет твоя система.
>>03910
Что тут непонятного?
Есть у тебя юзер, у него есть сертификаты и, скажем, ученые степени, всё в разных таблицах лежит. Вот ты будешь либо писать 3 запроса, чтобы достать юзера, сертификаты и степени, либо все будешь доставать в одном, используя джойны.
А в противовес этому у тебя есть просто объект "Юзер", с кучей атрибутов-массивов, который ты достаешь одним запросом. Это будет работать однозначно быстрее.
Я вообще не уверен, что есть какие-то дауны, которые считают, что надо только объектные БД использовать, патаму что удобнее. Просто в некоторых случаях удобно взять объект по ключу, который когда-то ты сохранил, тем более, что это будет быстрее. Эта скорость можно не замечать, когда у тебя 20 юзеров. Однако, если у тебя 20000000 юзеров, то тут каждая наносекунда может оказаться решающей.
А в каких-то случаях удобно использовать реляционку, потому что там все твёрдо и четко. Никто комбинированные подходы не отменял.
Например, юзаешь ты google firebase, как объектную БД, на фронте, а для автоматизации основных процессов компании юзаешь SQL Server на бэк-е с констрейнтами и прочими блэкджеками.
>>05288
Board:
id: integer unsigned primary key auto_increment not null
Thread:
id: integer unsigned primary key auto_increment not null,
board: id: integer unsigned not null,
post_id: integer unsigned not null //op post
Post:
id: integer unsigned primary key auto_increment not null
parent: id: integer unsigned not null // parent thread, 0 if it's op post
lasthit: timestamp not null
Вообщем надо получить все треды, к каждому по одному оп посту и еще 3 последних ответа к ним, отсортированных по lasthit.desc
Board:
id: integer unsigned primary key auto_increment not null
Thread:
id: integer unsigned primary key auto_increment not null,
board: id: integer unsigned not null,
post_id: integer unsigned not null //op post
Post:
id: integer unsigned primary key auto_increment not null
parent: id: integer unsigned not null // parent thread, 0 if it's op post
lasthit: timestamp not null
Вообщем надо получить все треды, к каждому по одному оп посту и еще 3 последних ответа к ним, отсортированных по lasthit.desc
>>05300
А СУБД какая?
тред и 3 поста должны быть в разных строчках или нет?
Например, в разных:
1. id = 1, thread_id = 1, is_thread = 1
2. id = 1, thread_id = 1, is_thread = 0
3. id = 2, thread_id = 1, is_thread = 0
4. id = 3, thread_id = 1, is_thread = 0
Если не в разныъ, тогда 3 строчки:
1. id = 1, thread_id = 1
2. id = 2, thread_id = 1
3. id = 3, thread_id = 1
Как ты хочешь?
А СУБД какая?
тред и 3 поста должны быть в разных строчках или нет?
Например, в разных:
1. id = 1, thread_id = 1, is_thread = 1
2. id = 1, thread_id = 1, is_thread = 0
3. id = 2, thread_id = 1, is_thread = 0
4. id = 3, thread_id = 1, is_thread = 0
Если не в разныъ, тогда 3 строчки:
1. id = 1, thread_id = 1
2. id = 2, thread_id = 1
3. id = 3, thread_id = 1
Как ты хочешь?
>>05330
а вообще тут как раз парадокс, что хотелось бы все сделать максимально пиздато, но приходится изобретать велосипеды, хотя я понимаю что можно как то 4 раза на один тред вернуть
(одинаковые значения треда + разный пост) и потом отсортировать это самому
а вообще тут как раз парадокс, что хотелось бы все сделать максимально пиздато, но приходится изобретать велосипеды, хотя я понимаю что можно как то 4 раза на один тред вернуть
(одинаковые значения треда + разный пост) и потом отсортировать это самому
>>05330
select
p.id
,p.id as thread_id
,lasthit
,1 as is_thread
from Post p
where p.parent = 0
union all
select
p.id
,p.parent as thread_id
,p.lasthit
,0 as is_thread
from (
select
t.id
,t.parent
,row_number() over (partition by parent order by lasthit desc) as
RN_post
from Post p
where p.parent_id <> 0
) p
where p.RN <=3
select
p.id
,p.id as thread_id
,lasthit
,1 as is_thread
from Post p
where p.parent = 0
union all
select
p.id
,p.parent as thread_id
,p.lasthit
,0 as is_thread
from (
select
t.id
,t.parent
,row_number() over (partition by parent order by lasthit desc) as
RN_post
from Post p
where p.parent_id <> 0
) p
where p.RN <=3
>>05346
-- достаём только по-посты (треды)
select
p.id
,p.id as thread_id
,lasthit
,1 as is_thread
from Post p
where p.parent = 0
union all
-- достаем ответы
select
p.id
,p.parent as thread_id
,p.lasthit
,0 as is_thread
from (
select
t.id
,t.parent
-- пронумеруем ответы в порядке убывания
,row_number() over (partition by parent order by lasthit desc) as
RN_post
from Post p
where p.parent <> 0
) p
where p.RN_post <=3 -- выбрем по 3 ответа (или меньше) к каждому треду
Пофиксил наименования
-- достаём только по-посты (треды)
select
p.id
,p.id as thread_id
,lasthit
,1 as is_thread
from Post p
where p.parent = 0
union all
-- достаем ответы
select
p.id
,p.parent as thread_id
,p.lasthit
,0 as is_thread
from (
select
t.id
,t.parent
-- пронумеруем ответы в порядке убывания
,row_number() over (partition by parent order by lasthit desc) as
RN_post
from Post p
where p.parent <> 0
) p
where p.RN_post <=3 -- выбрем по 3 ответа (или меньше) к каждому треду
Пофиксил наименования
>>05346
-- достаём только по-посты (треды)
select
p.id
,p.id as thread_id
,lasthit
,1 as is_thread
from Post p
where p.parent = 0
union all
-- достаем ответы
select
p.id
,p.parent as thread_id
,p.lasthit
,0 as is_thread
from (
select
t.id
,t.parent
-- пронумеруем ответы в порядке убывания
,row_number() over (partition by parent order by lasthit desc) as
RN_post
from Post p
where p.parent <> 0
) p
where p.RN_post <=3 -- выбрем по 3 ответа (или меньше) к каждому треду
Пофиксил наименования
-- достаём только по-посты (треды)
select
p.id
,p.id as thread_id
,lasthit
,1 as is_thread
from Post p
where p.parent = 0
union all
-- достаем ответы
select
p.id
,p.parent as thread_id
,p.lasthit
,0 as is_thread
from (
select
t.id
,t.parent
-- пронумеруем ответы в порядке убывания
,row_number() over (partition by parent order by lasthit desc) as
RN_post
from Post p
where p.parent <> 0
) p
where p.RN_post <=3 -- выбрем по 3 ответа (или меньше) к каждому треду
Пофиксил наименования
>>05366
Я же даже прокомментировал, что это значит.
https://mariadb.com/kb/en/library/row_number/
Я же даже прокомментировал, что это значит.
> пронумеруем ответы в порядке убывания
https://mariadb.com/kb/en/library/row_number/
>>05369
ок спасибо анон
ок спасибо анон
Хочу стать администратором баз данных
SQL и всё такое
С чего начинать и куда развиваться?
Стартовые характеристики:
27 лвл бизнесхуй
Образование - менеджмент
Шарю за ИТ на уровне админа локалки, эникея, линух-дрочера
SQL и всё такое
С чего начинать и куда развиваться?
Стартовые характеристики:
27 лвл бизнесхуй
Образование - менеджмент
Шарю за ИТ на уровне админа локалки, эникея, линух-дрочера
Пацаны, нид хелп.
Вкатывальщик тупит над задачей по СКюэЛь:
БД состоит из
Product(maker, model, type)
PC(code, model, speed, ram, hd, cd, price)
Laptop(code, model, speed, ram, hd, price, screen)
____________
Найдите номера моделей и цены всех имеющихся в продаже продуктов (любого типа) производителя B (латинская буква).
Мой солюшн:
SELECT CONCAT(PC.price, Laptop.price) AS price, CONCAT(
PC.model,Laptop.model) AS model FROM Product
INNER JOIN Laptop ON Laptop.model=Product.model
INNER JOIN PC ON PC.model=Product.model
WHERE Product.maker = 'B'
__________________
Результаты выполнения
Вашего запроса:
modelprice
правильного запроса:
pricemodel
1121850.0000
17501200.0000
Чую,косячу с иннер дойнами, по отдельности, вывожу по строчке.
Вкатывальщик тупит над задачей по СКюэЛь:
БД состоит из
Product(maker, model, type)
PC(code, model, speed, ram, hd, cd, price)
Laptop(code, model, speed, ram, hd, price, screen)
____________
Найдите номера моделей и цены всех имеющихся в продаже продуктов (любого типа) производителя B (латинская буква).
Мой солюшн:
SELECT CONCAT(PC.price, Laptop.price) AS price, CONCAT(
PC.model,Laptop.model) AS model FROM Product
INNER JOIN Laptop ON Laptop.model=Product.model
INNER JOIN PC ON PC.model=Product.model
WHERE Product.maker = 'B'
__________________
Результаты выполнения
Вашего запроса:
modelprice
правильного запроса:
pricemodel
1121850.0000
17501200.0000
Чую,косячу с иннер дойнами, по отдельности, вывожу по строчке.
Пацаны, нид хелп.
Вкатывальщик тупит над задачей по СКюэЛь:
БД состоит из
Product(maker, model, type)
PC(code, model, speed, ram, hd, cd, price)
Laptop(code, model, speed, ram, hd, price, screen)
____________
Найдите номера моделей и цены всех имеющихся в продаже продуктов (любого типа) производителя B (латинская буква).
Мой солюшн:
SELECT CONCAT(PC.price, Laptop.price) AS price, CONCAT(
PC.model,Laptop.model) AS model FROM Product
INNER JOIN Laptop ON Laptop.model=Product.model
INNER JOIN PC ON PC.model=Product.model
WHERE Product.maker = 'B'
__________________
Результаты выполнения
Вашего запроса:
modelprice
правильного запроса:
pricemodel
1121850.0000
17501200.0000
Чую,косячу с иннер дойнами, по отдельности, вывожу по строчке.
Вкатывальщик тупит над задачей по СКюэЛь:
БД состоит из
Product(maker, model, type)
PC(code, model, speed, ram, hd, cd, price)
Laptop(code, model, speed, ram, hd, price, screen)
____________
Найдите номера моделей и цены всех имеющихся в продаже продуктов (любого типа) производителя B (латинская буква).
Мой солюшн:
SELECT CONCAT(PC.price, Laptop.price) AS price, CONCAT(
PC.model,Laptop.model) AS model FROM Product
INNER JOIN Laptop ON Laptop.model=Product.model
INNER JOIN PC ON PC.model=Product.model
WHERE Product.maker = 'B'
__________________
Результаты выполнения
Вашего запроса:
modelprice
правильного запроса:
pricemodel
1121850.0000
17501200.0000
Чую,косячу с иннер дойнами, по отдельности, вывожу по строчке.
>>07244
судя по тому, что ты вхуярил concat, ты
1. не понимаешь, что тебе нужно сделать
2. не понимаешь, что ты делаешь
тут тебе не поможешь
судя по тому, что ты вхуярил concat, ты
1. не понимаешь, что тебе нужно сделать
2. не понимаешь, что ты делаешь
тут тебе не поможешь
>>07344
Да он перепутал просто конакт и коалис
Да он перепутал просто конакт и коалис
SQL-господа, надо за два дня постичь основы SQL, чтобы написать тз (по основам JS, SQL и сисярп) и попасть на курсы. Подскажите, пожалуйста, как это реализовать? На всё у меня в сумме неделя.
Что за уебаны в треде?
>>02870 (OP)
Что скажете за оптимизацию запросов в оракеле? Где есть нормальная документация?
Что скажете за оптимизацию запросов в оракеле? Где есть нормальная документация?
>>08322
А чем оптимизация в оракле отличается от оптимизации в sql-сервере?
Кури гайды по чтению плана запроса.
А чем оптимизация в оракле отличается от оптимизации в sql-сервере?
Кури гайды по чтению плана запроса.
>>05288
Т.е. требуя не поломать целостность. Для этого FK и нужен. Больше ни для чего. Чтобы красноглазик не объебался, и не засрал базу непонятными данными.
Не могу себе представить рабочую OLTP-систему, в которой кто-то не создал FK constraint "потому что придется каскадно удалять" или "потому что медленно".
Если какой-то второй уровень уже, типа витрины или хранилища, куда данные выгружаются из заведомо целостной (потому что там есть ФК) базы, то могу себе представить, что не делают целый ряд вещей, без которых немыслимо первичное хранение.
FK это НЕ СВЯЗЬ!!!!!!!
>ForeignKey, Действительно, не всегда используют, потому что он еще и усложняет саму разработку, требуя производить каскадное удаление записей, например.
Т.е. требуя не поломать целостность. Для этого FK и нужен. Больше ни для чего. Чтобы красноглазик не объебался, и не засрал базу непонятными данными.
Не могу себе представить рабочую OLTP-систему, в которой кто-то не создал FK constraint "потому что придется каскадно удалять" или "потому что медленно".
Если какой-то второй уровень уже, типа витрины или хранилища, куда данные выгружаются из заведомо целостной (потому что там есть ФК) базы, то могу себе представить, что не делают целый ряд вещей, без которых немыслимо первичное хранение.
>Но стоит помнить, что, чем меньше у тебя связей между таблицами, тем менее целостной будет твоя система.
FK это НЕ СВЯЗЬ!!!!!!!
>>05288
Но мне (да и тебе, уверен тоже) почти никогда не нужен ВЕСЬ объект Юзер.
Что, если тебе надо взять просто ФИО и дату рождения?
А что если только ПОСЛЕДНИЙ по дате сертификат?
А что, если тебе надо взять Юзеров, у которых есть такие же сертификаты как у Пупкина?
Т.е., очевидно, я понимаю, что один кусок достать одним куском проще, чем собрать по частям.
Но посмотри же внимательнее на мои вопросы:
что это за ситуации, когда все всегда нужно одним куском?
Мне не приходилось таких систем видеть.
>Есть у тебя юзер, у него есть сертификаты и, скажем, ученые степени, всё в разных таблицах лежит.
>....
>А в противовес этому у тебя есть просто объект "Юзер", с кучей атрибутов-массивов, который ты достаешь одним запросом. Это будет работать однозначно быстрее.
Но мне (да и тебе, уверен тоже) почти никогда не нужен ВЕСЬ объект Юзер.
Что, если тебе надо взять просто ФИО и дату рождения?
А что если только ПОСЛЕДНИЙ по дате сертификат?
А что, если тебе надо взять Юзеров, у которых есть такие же сертификаты как у Пупкина?
Т.е., очевидно, я понимаю, что один кусок достать одним куском проще, чем собрать по частям.
Но посмотри же внимательнее на мои вопросы:
что это за ситуации, когда все всегда нужно одним куском?
Мне не приходилось таких систем видеть.
>>09922
Пидорасы, сэр. Кругом одни формошлёпы и асинхронные дрочеры.
Сам ищу чего бы почитать по логическому проектированию БД. Запросы писать умею, таблицы состряпаю, но хотелось бы чего-нибудь фундаментального.
Пидорасы, сэр. Кругом одни формошлёпы и асинхронные дрочеры.
Сам ищу чего бы почитать по логическому проектированию БД. Запросы писать умею, таблицы состряпаю, но хотелось бы чего-нибудь фундаментального.
>>10795
И я бы хотел. Вон там чувак сверху писал
Вот где прочесть как разрабатывать хранилища данных, чем эта абстракция или не абстракция? отличается от просто кучи таблиц в БД? НИПАНЯТНА
И я бы хотел. Вон там чувак сверху писал
>Например, при разработке хранилища данных не принято использовать Foreign key, чтобы не усложнять и без того тяжелые инсерты.
Вот где прочесть как разрабатывать хранилища данных, чем эта абстракция или не абстракция? отличается от просто кучи таблиц в БД? НИПАНЯТНА
DBАноны, сам я пхп-макака, и недавно прочитал умные статьи с критикой ORM, решил упороться и изучить подробнее sql и базы даных, выбор пал на postgres. Сейчас на работе у нас все хранится в mariadb, около полумиллиона записей в 30 таблицах. Очень много ненужных колонок, нарушены нормальные формы, чувак думал в парадигме ООП, и засрал базу. Можно ли все это перенести в postgresql, и начать рефакторинг, и выжимать по полной из базы, удалив мусорный код, или это нереальная задача и стоит забить?
>>09654
fk это constraint. ограничение.
правило, которое определяет, что может, а чего не может быть в поле.
Новичкам кажется, что fk определяет какую-то связь, которая что-то о чем-то говорит, и чем-то может помочь при селектах.
Но это не так. Где-то там, в эмпиреях, это, может, и связь. Но на уровне схемы БД, инсертов, апдейтов и делитов, это просто правило, которое определяет возможные значения и правила удаления.
fk это constraint. ограничение.
правило, которое определяет, что может, а чего не может быть в поле.
Новичкам кажется, что fk определяет какую-то связь, которая что-то о чем-то говорит, и чем-то может помочь при селектах.
Но это не так. Где-то там, в эмпиреях, это, может, и связь. Но на уровне схемы БД, инсертов, апдейтов и делитов, это просто правило, которое определяет возможные значения и правила удаления.
>>10836
Кто мешает тебе заглянуть хотя бы в википедию?
The data stored in the warehouse is uploaded from the operational systems (such as marketing or sales). The data may pass through an operational data store and may require data cleansing[2] for additional operations to ensure data quality before it is used in the DW for reporting.
Разница в том, что "куча таблиц в БД" заточена под оперативную обработку, в которой любая ошибка может привести к битым данным. Поэтому любой вменяемый архитектор обкладывает базу всеми возможными констрейнтами, чтобы говнокодеры не засрали базу.
Хранилище данных строится поверх оперативной БД. Если ты объебешься и зальешь кривые данные в хранилище, это не очень страшно. Потому что исходные данные все еще целостные и правильные. Исправишь ошибку и перезальешь свое хранилище.
Кто мешает тебе заглянуть хотя бы в википедию?
The data stored in the warehouse is uploaded from the operational systems (such as marketing or sales). The data may pass through an operational data store and may require data cleansing[2] for additional operations to ensure data quality before it is used in the DW for reporting.
Разница в том, что "куча таблиц в БД" заточена под оперативную обработку, в которой любая ошибка может привести к битым данным. Поэтому любой вменяемый архитектор обкладывает базу всеми возможными констрейнтами, чтобы говнокодеры не засрали базу.
Хранилище данных строится поверх оперативной БД. Если ты объебешься и зальешь кривые данные в хранилище, это не очень страшно. Потому что исходные данные все еще целостные и правильные. Исправишь ошибку и перезальешь свое хранилище.
>>10972
Просто правило - это constraint
Когда создаешь fk, пишешь references, что переводится, как «ссылается». Так что не пизди тут про несвязь.
Просто правило - это constraint
Когда создаешь fk, пишешь references, что переводится, как «ссылается». Так что не пизди тут про несвязь.
>>10952
Можно
Можно
>>11128
Ну да, связь - это же от слова «вязать». Никто же не вяжет ничего в базе данных, ниточек там нет, вот и связи нет.
Такая у тебя логика.
Ну да, связь - это же от слова «вязать». Никто же не вяжет ничего в базе данных, ниточек там нет, вот и связи нет.
Такая у тебя логика.
Товарищи,
Кто-нибудь писал парсеры логов БД? Прочитать бинарник - вернуть данные.
В частности интересует redo оракловый.
Может кто обладает тайными знаниями, из каких структур и каких размерностей состоит лог? Конкретной разбивки с типами данных и их размерностями нагуглить пока не удалось.
Или вы знаете про конкретные непреодолимые препятсвия, которые могут возникнуть во время решения этой задачи.
Для трэйла oracle gg получилось провернуть такую штуку, хочу с redo попробовать.
Кто-нибудь писал парсеры логов БД? Прочитать бинарник - вернуть данные.
В частности интересует redo оракловый.
Может кто обладает тайными знаниями, из каких структур и каких размерностей состоит лог? Конкретной разбивки с типами данных и их размерностями нагуглить пока не удалось.
Или вы знаете про конкретные непреодолимые препятсвия, которые могут возникнуть во время решения этой задачи.
Для трэйла oracle gg получилось провернуть такую штуку, хочу с redo попробовать.
>>10976
Прочёл. Да, хорошая книга, но многабукав (воды), при том что это труд о БД в принципе. Много вещей которые и так интуитивно понятны, а вот эффективных запросов или построения моделей данных нет.
Прочёл. Да, хорошая книга, но многабукав (воды), при том что это труд о БД в принципе. Много вещей которые и так интуитивно понятны, а вот эффективных запросов или построения моделей данных нет.
>>10976
Да и в принципе книжка очень старая. И примеров на реальных СУБД не хватает. А там за 20 лет кучу фич запилили.
Да и в принципе книжка очень старая. И примеров на реальных СУБД не хватает. А там за 20 лет кучу фич запилили.
Собираюсь запилить БД "склада" на строительном объекте. Думаю пилить на Access, но закрадываются мысли таки мутить на MS SQL или на MySQL. Таки посоветуйте нубу, на чом пилить?
>>11618
Мне кажется, недостаточно вводных.
MS SQL почти во всех изданиях платный.
Есть Express-версия с разрешенным объемом в 10 гб и незапускающимся агентом.
Есть Developer-версия, полностью работающая, но якобы только для разработки, как они это проверяют, я хз.
Access - это что-то уровня SQLite или Excel, если планируешь организовывать туда доступ разным пользователям с разграничением прав, то не уверен, что это то, что надо. С другой стороны, в Access есть встроенный редактор форм, так что, если не умеешь прогать, а хочешь создавать интерфейсы, то это будет самым простым вариантом.
Мне кажется, недостаточно вводных.
MS SQL почти во всех изданиях платный.
Есть Express-версия с разрешенным объемом в 10 гб и незапускающимся агентом.
Есть Developer-версия, полностью работающая, но якобы только для разработки, как они это проверяют, я хз.
Access - это что-то уровня SQLite или Excel, если планируешь организовывать туда доступ разным пользователям с разграничением прав, то не уверен, что это то, что надо. С другой стороны, в Access есть встроенный редактор форм, так что, если не умеешь прогать, а хочешь создавать интерфейсы, то это будет самым простым вариантом.
>>11626
это
Но пытаюсь учиться. Таки попробую в Access, если приспичит дальше развивать, буду изучать взрослые СУБД
>если не умеешь прогать
это
Но пытаюсь учиться. Таки попробую в Access, если приспичит дальше развивать, буду изучать взрослые СУБД
>>11618
Делай нормально, асес гавно мамонта какое-то. Бери май или мс. У мс есть экспресс бесплатная, если у тебя там не хайлоад разницы не заметишь. С мсовской в комплекте идет менеджмент студио, у май тоже есть из коробки инструменты все. Какой в очко ассес перекрестился
Делай нормально, асес гавно мамонта какое-то. Бери май или мс. У мс есть экспресс бесплатная, если у тебя там не хайлоад разницы не заметишь. С мсовской в комплекте идет менеджмент студио, у май тоже есть из коробки инструменты все. Какой в очко ассес перекрестился
Анон, а поясни для суперньюфага, в чем разница между MySQL, MS SQL Server, SQLite, Postgres и всякими другими бд?
Я щас вот сижу учу SQL, всякие эти селекты-хуекты, и туториал меня ведет по SQL Server. Но я же так понимаю, SQL будет везде одинаковый? И во всех БД запросы выглядят абсолютно одинаково?
Я щас вот сижу учу SQL, всякие эти селекты-хуекты, и туториал меня ведет по SQL Server. Но я же так понимаю, SQL будет везде одинаковый? И во всех БД запросы выглядят абсолютно одинаково?
>>11736
это все демоны, к которым ты можешь подключаться удаленно
устаревшее говно, use mariadb instead
вроде годнота, и можно после инсерта получить инфу о поле, которое вставил, но есть и свои недостатки, увы тут я хз.
говно
в синтакисе есть подьеб AUTOINCREMENT, а так годнота, особенно для игр, но для хайлоад прочих PoolConnection не поедет, так как не поддерживает несколько соеденений (онли одно).
>MySQL, Postgres, MS SQL Server
это все демоны, к которым ты можешь подключаться удаленно
>мускул
устаревшее говно, use mariadb instead
>постгря
вроде годнота, и можно после инсерта получить инфу о поле, которое вставил, но есть и свои недостатки, увы тут я хз.
>мс
говно
>Sqlite3
в синтакисе есть подьеб AUTOINCREMENT, а так годнота, особенно для игр, но для хайлоад прочих PoolConnection не поедет, так как не поддерживает несколько соеденений (онли одно).
>>11741
Т.е. по большому счету все равно, на какой ДБ учиться писать запросы? Я не планирую быть архитектором баз данных, вообще мечу в бэкэнд, так что мне, по сути, надо просто понимать, как и какие запросы писать в БД.
Т.е. по большому счету все равно, на какой ДБ учиться писать запросы? Я не планирую быть архитектором баз данных, вообще мечу в бэкэнд, так что мне, по сути, надо просто понимать, как и какие запросы писать в БД.
>>11654
Подключайся, помогай составить
Подключайся, помогай составить
Есть некие изделия с фиксированным диапазоном длин, ширин, высот и некоторых особенностей. Например: ящик 1х0.5х0.7м с отверстием/центральным отверстием/без отверстия Писать каждый экземпляр в таблицу или создать таблицы ширина, длина, высота и поле "отверстие" с выпадающим списком и вставлять данные из них в таблицу "Ящики"?
>>11793
Наименование-размер-отверстие(тру/фальш). Стоит ли размер разбивать на части зависит от условий, если разбить можно будет искать по каждой стороне.
Наименование-размер-отверстие(тру/фальш). Стоит ли размер разбивать на части зависит от условий, если разбить можно будет искать по каждой стороне.
>>11736
В основной своей массе - да.
У всех есть какие-то свои расширения.
У говна типа мускл есть еще и свои тупые ограничения.
Некоторые (типа того же мускла) херово умеют в стандарт.
Но это SQL.
Как только ты шагнешь в процедурность, у всех все будет разное.
Средства оптимизмации тоже у всех более-менее разные.
>SQL будет везде одинаковый
В основной своей массе - да.
У всех есть какие-то свои расширения.
У говна типа мускл есть еще и свои тупые ограничения.
Некоторые (типа того же мускла) херово умеют в стандарт.
Но это SQL.
Как только ты шагнешь в процедурность, у всех все будет разное.
Средства оптимизмации тоже у всех более-менее разные.
Решил вкатится в вашу парашу. Что за пиздец с литературой? Книги хер найдешь, а те что есть написаны хуй пойми как. По сранному виму наверное больше книг чем по скулю.
Есть ли есть что-нибудь годное покурить кидайте
Есть ли есть что-нибудь годное покурить кидайте
594 Кб, 1282x825>>12230
Вот что это блядь такое? Какая-то бабка собралась учить SQL, они что там ебанулись в своей майкрософт? И так в каждом втором руководсвте\книжке, какая-то дичь. Неужели весь этот sql настолько некому в хуй не упёрся?
Вот что это блядь такое? Какая-то бабка собралась учить SQL, они что там ебанулись в своей майкрософт? И так в каждом втором руководсвте\книжке, какая-то дичь. Неужели весь этот sql настолько некому в хуй не упёрся?
>>12264
У меня в вузике SQL преподавала женщина. И она в нем более-менее разбиралась.
Уперся практически везде, особенно в вебе. Я рискну предположить, sql преподают всякие бабки, потому что это один из самых простых топиков it, по крайней мере что касается основ.
У меня в вузике SQL преподавала женщина. И она в нем более-менее разбиралась.
>Неужели весь этот sql настолько некому в хуй не упёрся?
Уперся практически везде, особенно в вебе. Я рискну предположить, sql преподают всякие бабки, потому что это один из самых простых топиков it, по крайней мере что касается основ.
>>12468
Аргументация в уровня /b.
Аргументация в уровня /b.
Правда ли что
SELECT COUNT(*) FROM table
Не атомарная операция и проходит по всей таблице?
В что там свитера, совсем ебанулись?
SELECT COUNT(*) FROM table
Не атомарная операция и проходит по всей таблице?
В что там свитера, совсем ебанулись?
>>12513
Вероятно, зависит от реализации. Может какая-нибудь count(*) понимает как "количество строк с хотя бы одним не-нулл полем".
Попробуй select count(1) from table
Вероятно, зависит от реализации. Может какая-нибудь count(*) понимает как "количество строк с хотя бы одним не-нулл полем".
Попробуй select count(1) from table
>>12513>>12515
The basic SQL standard query to count the rows in a table is:
SELECT COUNT(*) FROM TABLE_NAME;
This can be rather slow because PostgreSQL has to check visibility for all rows, due to the MVCC model. (There have been improvements in PostgreSQL 9.2.)
If you don't need an exact count, the current statistic from the catalog table pg_class might be good enough and is much faster to retrieve for big tables.
SELECT reltuples AS approximate_row_count FROM pg_class WHERE relname = 'table_name';
Это во всех БД так или только в самых ебнутых? Или как обычно у свитеров полный разброд и никто ничего не знает и сказать не может наверняка?
The basic SQL standard query to count the rows in a table is:
SELECT COUNT(*) FROM TABLE_NAME;
This can be rather slow because PostgreSQL has to check visibility for all rows, due to the MVCC model. (There have been improvements in PostgreSQL 9.2.)
If you don't need an exact count, the current statistic from the catalog table pg_class might be good enough and is much faster to retrieve for big tables.
SELECT reltuples AS approximate_row_count FROM pg_class WHERE relname = 'table_name';
Это во всех БД так или только в самых ебнутых? Или как обычно у свитеров полный разброд и никто ничего не знает и сказать не может наверняка?
>>12528
Это шизик, ему неинтересно, он просто хочет срач, игнорируй его.
Это шизик, ему неинтересно, он просто хочет срач, игнорируй его.
>>12997
Не передергивай, одно дело писать запросики уровня "Покажи всех студентов старше 20 плиз)))", другое дело реально в этом всем разбираться. Первого для повседневных задач хватает с головой и большинство макак и знать не знают, что там за реляционная алгебра, потому что им это нахуй не надо.
Не передергивай, одно дело писать запросики уровня "Покажи всех студентов старше 20 плиз)))", другое дело реально в этом всем разбираться. Первого для повседневных задач хватает с головой и большинство макак и знать не знают, что там за реляционная алгебра, потому что им это нахуй не надо.
>>13004
Жду, когда ты, умник, боевую картиночку подтащишь
Жду, когда ты, умник, боевую картиночку подтащишь
>>13067
Реляционная алгебра в любом учебнике по БД, пусть даже строго написанном, это поверхностная глава из серии "вот есть базовые операции, их можно комбинировать и найти какое хошь отношение хахааа", то есть ничего умного или полезного, если ты серьезный кампустир саентист и тебе реально надо в этом какие-то теоремы доказывать, то надо статьи читать по теме, а то пафосно названный "реляционная теория" раздел из книжки как раз для тех самых макак-второкурсников.
Реляционная алгебра в любом учебнике по БД, пусть даже строго написанном, это поверхностная глава из серии "вот есть базовые операции, их можно комбинировать и найти какое хошь отношение хахааа", то есть ничего умного или полезного, если ты серьезный кампустир саентист и тебе реально надо в этом какие-то теоремы доказывать, то надо статьи читать по теме, а то пафосно названный "реляционная теория" раздел из книжки как раз для тех самых макак-второкурсников.
296 Кб, 350x296>>13234
Чот проиграл
Чот проиграл
>>08813
Так оно и не для крудоговна нужно. Например представь микросервис в большой системе которому несколько раз в час насирают миллионы сообщений и которые он должен потом постепенно обработать, никакого смысла тут реляционки использовать очевидно нет.
Так оно и не для крудоговна нужно. Например представь микросервис в большой системе которому несколько раз в час насирают миллионы сообщений и которые он должен потом постепенно обработать, никакого смысла тут реляционки использовать очевидно нет.
>>13225
Как что-то плохое.
Как что-то плохое.
>>13270
Так я про то и спрашивал - где используется.
Но читая статьи зумеров для зумеров, я подозреваю, что они-то жаждут это использовать везде.
node.js + mongodb = 33 млн. в выдаче гугла.
Не устаю проигрывать с непроходящей стадии отрицания у анонов.
"крудоговно" это то, на чем работает абсолютно все.
Это как свысока рассуждать о "дыханиеговне" и прочем обмене веществ.
Мол, я весь в эмпиреях витаю, я выше всего этого.
Так я про то и спрашивал - где используется.
Но читая статьи зумеров для зумеров, я подозреваю, что они-то жаждут это использовать везде.
node.js + mongodb = 33 млн. в выдаче гугла.
>крудоговна
Не устаю проигрывать с непроходящей стадии отрицания у анонов.
"крудоговно" это то, на чем работает абсолютно все.
Это как свысока рассуждать о "дыханиеговне" и прочем обмене веществ.
Мол, я весь в эмпиреях витаю, я выше всего этого.
>>02870 (OP)
Аноны памагите плисс!!!
1 Выведите количество значений Customers в каждой
стране.
SELECT (CustomerID),
Country
FROM Customers
;
2 Выведите количество покупателей в каждом городе,
выравнивая по возрастанию их количества
SELECT (CustomerID),
Country
FROM Customers
ORDER BY ;
Аноны памагите плисс!!!
1 Выведите количество значений Customers в каждой
стране.
SELECT (CustomerID),
Country
FROM Customers
;
2 Выведите количество покупателей в каждом городе,
выравнивая по возрастанию их количества
SELECT (CustomerID),
Country
FROM Customers
ORDER BY ;
Аноны, какие есть годные книги по SQl (mariadb) для продвинутого уровня? Где подробно разбирают оптимизацию кода, разные фичи типо from (select ...) a и т.д?
>>14556
Group by а помощь. Таблицы из нортвинда.
Group by а помощь. Таблицы из нортвинда.
>>14623
А что не так? Все лютое говно как раз в селектах.
А что не так? Все лютое говно как раз в селектах.
>>03718
nedb так и делает, в общем-то.
nedb так и делает, в общем-то.
Подходит ли MongoDB для проектов с реляционными данными (через DBRef)? Хочу использовать в проекте Spring Webflux, но неблокирующих драйверов для реляционных БД пока не завезли, поэтому планирую использовать Mongo как основную БД. Это норм затея?
232 Кб, 1853x1050Аноны, помогите с laba2, пожалуйста
ругается на синтаксическую ошибку в месте вызова функции, которая возвращает селект. если вместо вызова функции вставить целиком селект, то все работает. чому так?
скобки вокруг EXISTS поставил от отчания, без них такую же ошибку выдает
ругается на синтаксическую ошибку в месте вызова функции, которая возвращает селект. если вместо вызова функции вставить целиком селект, то все работает. чому так?
скобки вокруг EXISTS поставил от отчания, без них такую же ошибку выдает
>>14926
Да, тогда все ок. Действуй, сестра!
Да, тогда все ок. Действуй, сестра!
>>14921
exists select * from select_time_intersection
чо, в гугле забанили, что ли?
или лень почитать, что означает returns table и как с ей жить?
exists select * from select_time_intersection
чо, в гугле забанили, что ли?
или лень почитать, что означает returns table и как с ей жить?
>>15211
Ты должен благодарить Аллаха за то что направил твой разум, а не кефира
Ты должен благодарить Аллаха за то что направил твой разум, а не кефира
Пацаны, есть поле с типом varchar(10)
И когда я туда попытался занести строку из 11 символов, мне выдало ошибку. ERROR 1406 (22001): Data too long for column
Я понимаю, если бы это был char(10), но это var ебать его в сраку char, он должон изменяться! Почему так?
И когда я туда попытался занести строку из 11 символов, мне выдало ошибку. ERROR 1406 (22001): Data too long for column
Я понимаю, если бы это был char(10), но это var ебать его в сраку char, он должон изменяться! Почему так?
>>15389
чтоб оно изменилось 10 не должно быть. Десяткой ты задаешь фиксированную длину, схуяли оно должно меняться?
чтоб оно изменилось 10 не должно быть. Десяткой ты задаешь фиксированную длину, схуяли оно должно меняться?
>>15486
10 это максимум, если у тебя меньше, оно меньеш выделит памяти, а если больше, то ты пойдёшь нахуй.
10 это максимум, если у тебя меньше, оно меньеш выделит памяти, а если больше, то ты пойдёшь нахуй.
>>15497
Почему тупые вопросы у тебя, а далбаёбы мы?
Почему тупые вопросы у тебя, а далбаёбы мы?
55 Кб, 804x743Есть ли альтернатива для хранения данных в большом количестве однотипных полей? Суть в том, что у меня есть таблица с игроками, где у каждого игрока свой уникальный id. Так же есть таблица с историей матчей, где у каждого матча есть уникальный id и 10 полей, содержащих id всех игроков, которые в нем участвовали. Насколько это практичное решение? Или можно как-то эти 10 столбцов заменить одним? Если нет, то нужно и можно ли эти 10 столбцов помечать внешним ключом?
>>15612
Если матчи парные можно сделать две таблицы с победителями и с проигравшими, или сделать две таблицы Матч и Детали матча, к которой можно будет обратится если нужны подробности.
Если матчи парные можно сделать две таблицы с победителями и с проигравшими, или сделать две таблицы Матч и Детали матча, к которой можно будет обратится если нужны подробности.
>>15639
Детали матча это уже третья таблица. Там будет много уникальных полей для каждого игрока в данном матче. А насчет двух таблиц с победителями и проигравшими, как это упрощает менеджмет бд? Это же вместо 1 таблицы с 10 столбцами - 2 таблицы с 5 столбцами каждая. Если я правильно понял.
Детали матча это уже третья таблица. Там будет много уникальных полей для каждого игрока в данном матче. А насчет двух таблиц с победителями и проигравшими, как это упрощает менеджмет бд? Это же вместо 1 таблицы с 10 столбцами - 2 таблицы с 5 столбцами каждая. Если я правильно понял.
>>15645
Ну тут зависит от такого насколько тебе подробные нужны результаты, можно просто сделать графу ПОБЕДИТЕЛЬ в главной таблице
Ну тут зависит от такого насколько тебе подробные нужны результаты, можно просто сделать графу ПОБЕДИТЕЛЬ в главной таблице
>>15657
Не, подробные данные нужны для всех игроков, просто, когда много однотипных столбцов, хочется это как-то упростить. Если я этого анона >>15622 правильно понял, то так, наверное, и сделаю. Эта таблица >>15632 просто будет продолжена на 50+ столбцов, которые тоже бы, наверное, стоило как-то распределить, но и разрастаться таблицами тоже не хочется. К тому же, данные там почти уникальные.
Не, подробные данные нужны для всех игроков, просто, когда много однотипных столбцов, хочется это как-то упростить. Если я этого анона >>15622 правильно понял, то так, наверное, и сделаю. Эта таблица >>15632 просто будет продолжена на 50+ столбцов, которые тоже бы, наверное, стоило как-то распределить, но и разрастаться таблицами тоже не хочется. К тому же, данные там почти уникальные.
>>15632
Так, да.
Потом у тебя случится замена, и вместо 10-ти игроков в матче будет 11.
А потом кого-нибудь удалят до стартового свистка и будет 9.
Можно, конечно, не делать суррогатный ключ, а сразу захерачить композитный на ид_матч и ид_плейер.
Это как удобнее. Про отдельный ПК я на всякий случай упомянул.
Так, да.
Потом у тебя случится замена, и вместо 10-ти игроков в матче будет 11.
А потом кого-нибудь удалят до стартового свистка и будет 9.
Можно, конечно, не делать суррогатный ключ, а сразу захерачить композитный на ид_матч и ид_плейер.
Это как удобнее. Про отдельный ПК я на всякий случай упомянул.
>>12524
Бамп вопросу, хули отмалчиваетесь?
Бамп вопросу, хули отмалчиваетесь?
>>02870 (OP)
Что за конкаренси-шизик? Я не в курсе, первый раз в треде, объясните пожалуйста.
Что за конкаренси-шизик? Я не в курсе, первый раз в треде, объясните пожалуйста.
>>08813
GraphQL
> Но мне (да и тебе, уверен тоже) почти никогда не нужен ВЕСЬ объект Юзер.
> Что, если тебе надо взять просто ФИО и дату рождения?
> А что если только ПОСЛЕДНИЙ по дате сертификат?
> А что, если тебе надо взять Юзеров, у которых есть такие же сертификаты как у Пупкина?
GraphQL
>>16013
но тебе из них нужны только фамилии
а ты все объекты будешь подтягивать
короче, я так пока и не понял этого дроча
но тебе из них нужны только фамилии
а ты все объекты будешь подтягивать
короче, я так пока и не понял этого дроча
Мы учим эту тему в универе, пишем по ней курсачи, кажется несложным. На этом можно зарабатывать какие-то деньги? Если да, то какие и где удаленно естественно студентота нищая
>>16028
В офисе сначала поработай, а потом уж лезь в удалёнку.
В офисе сначала поработай, а потом уж лезь в удалёнку.
>>16028
Да иди ты нахуй. Почему мне кажется скл запросы и иже с ними самой сложной темой в погромиравании, завидую тебе пиздец...
Да иди ты нахуй. Почему мне кажется скл запросы и иже с ними самой сложной темой в погромиравании, завидую тебе пиздец...
Сап, запросач, посоветуй где и что можно почитать про хранимые процедуры и функции, если для совсем тупых и с примерами, то вообще шикарно.
Алсо, это я криворучка или консоль у Open Server не очень?
мимо делаю лабы
Алсо, это я криворучка или консоль у Open Server не очень?
мимо делаю лабы
Сколько внешние ключи занимают места в БД? Нигде не смог найти ответа на этот вопрос. Они явно же не просто так придуманы были... И если они действительно меньше места занимают, то насколько примерно?
>>16236
1. что значит "занимают места в БД"?
2. "они действительно меньше места занимают" - меньше, чем что?
>>16246
Блядь, опять ебаные связи.
Анон вообще не понимает, что зачем нужно, ты ему пудришь мозги какими-то связями.
Пусть R1 и R2 — две переменные отношения, не обязательно различные. Внешним ключом FK в R2 является подмножество атрибутов переменной R2 такое, что выполняются следующие требования:
В переменной отношения R1 имеется потенциальный ключ CK такой, что FK и CK совпадают с точностью до переименования атрибутов (то есть переименованием некоторого подмножества атрибутов FK можно получить такое подмножество атрибутов FK’, что FK’ и CK совпадают как по именами, так и по типам атрибутов).
В любой момент времени каждое значение FK в текущем значении R2 идентично значению CK в некотором кортеже в текущем значении R1. Иными словами, в каждый момент времени множество всех значений FK в R2 является (нестрогим) подмножеством значений CK в R1.
При этом для данного конкретного внешнего ключа FK → CK отношение R1, содержащее потенциальный ключ, называют главным, целевым, или родительским отношением, а отношение R2, содержащее внешний ключ, называют подчинённым, или дочерним отношением.
Охуенная связь, ага
1. что значит "занимают места в БД"?
2. "они действительно меньше места занимают" - меньше, чем что?
>>16246
Блядь, опять ебаные связи.
Анон вообще не понимает, что зачем нужно, ты ему пудришь мозги какими-то связями.
Пусть R1 и R2 — две переменные отношения, не обязательно различные. Внешним ключом FK в R2 является подмножество атрибутов переменной R2 такое, что выполняются следующие требования:
В переменной отношения R1 имеется потенциальный ключ CK такой, что FK и CK совпадают с точностью до переименования атрибутов (то есть переименованием некоторого подмножества атрибутов FK можно получить такое подмножество атрибутов FK’, что FK’ и CK совпадают как по именами, так и по типам атрибутов).
В любой момент времени каждое значение FK в текущем значении R2 идентично значению CK в некотором кортеже в текущем значении R1. Иными словами, в каждый момент времени множество всех значений FK в R2 является (нестрогим) подмножеством значений CK в R1.
При этом для данного конкретного внешнего ключа FK → CK отношение R1, содержащее потенциальный ключ, называют главным, целевым, или родительским отношением, а отношение R2, содержащее внешний ключ, называют подчинённым, или дочерним отношением.
Охуенная связь, ага
>>16252
Любая БД занимает место на носителе информации. БД хранит свои заголовки для интерпретации СУБД, названия таблиц, названия полей, сами значения полей. Размер значений зависит от типа данных, но помимо обычных полей, есть свойство полей - внешний ключ. Из того, что прочитал, так это то, что они позволяют искать данные в БД быстрее, а про занимаемое ими место ни слова. Ибо мне представляется, что раз они используются в качестве индексов, то и повторное их использование в таблицах по факту не должно занимать никакого места. Т.е. это примерно, как указатели в c/c++. Можно создать тысячи указателей на один объект, но при этом память выделяться для каждого указателя под размер этого объекта не будет. Вот я и хочу понять: так ли это?
Т.е. если у меня есть таблица peoples (id, name, country_id), где country_id - внешний ключ к полю id таблицы countries (id, name), то при наличии 100 записей в этом поле фактически будет выделено место только под размер таблицы countries, где всего может быть только 5 стран. А country_id будет только указателем. Как-то так...
Любая БД занимает место на носителе информации. БД хранит свои заголовки для интерпретации СУБД, названия таблиц, названия полей, сами значения полей. Размер значений зависит от типа данных, но помимо обычных полей, есть свойство полей - внешний ключ. Из того, что прочитал, так это то, что они позволяют искать данные в БД быстрее, а про занимаемое ими место ни слова. Ибо мне представляется, что раз они используются в качестве индексов, то и повторное их использование в таблицах по факту не должно занимать никакого места. Т.е. это примерно, как указатели в c/c++. Можно создать тысячи указателей на один объект, но при этом память выделяться для каждого указателя под размер этого объекта не будет. Вот я и хочу понять: так ли это?
Т.е. если у меня есть таблица peoples (id, name, country_id), где country_id - внешний ключ к полю id таблицы countries (id, name), то при наличии 100 записей в этом поле фактически будет выделено место только под размер таблицы countries, где всего может быть только 5 стран. А country_id будет только указателем. Как-то так...
>>16275
Тебе нужно гуглить реализацию по конкретной базе.
Сильно сомневаюсь, что есть базы с реализацией fk через ссылки. Как минимум это выльется в массовый апдейт при удалении fk.
Fk относится к обьектам типа constraint, в oracle по крайней мере.
То есть по факту, это свод ограничений, проверок, которые срабатывают при добавлении/изменении значений в поле, на которое наложен constraint.
В случае FK в качестве вспомогательной структуры, для поддержи constraint используется уникальный индекс таблицы, на! котрую ссылается поле с FK.
То есть сам FK не создает доп структур с данными для своего функционирования.
Однако в поле с FK, хранятся полноценные данные, а не ссылки на данные из другой таблици. Просто при вставке нового значения в поле, дергается индекс таблицы на котрую ссылается поле, и производится проверка, есть ли там такое значение.
По поводу ускорения поиска интересный вопрос, но насколько я знаю, сам по себе constraint не дает выйгрышей по производительности и индекс не создает. (Not null может давать, с той точки зрения, что будут строится более оптимальные планы, для некоторых запросов, но сейчас не об этом)
Все вышесказанное относится к бд oracle
Тебе нужно гуглить реализацию по конкретной базе.
Сильно сомневаюсь, что есть базы с реализацией fk через ссылки. Как минимум это выльется в массовый апдейт при удалении fk.
Fk относится к обьектам типа constraint, в oracle по крайней мере.
То есть по факту, это свод ограничений, проверок, которые срабатывают при добавлении/изменении значений в поле, на которое наложен constraint.
В случае FK в качестве вспомогательной структуры, для поддержи constraint используется уникальный индекс таблицы, на! котрую ссылается поле с FK.
То есть сам FK не создает доп структур с данными для своего функционирования.
Однако в поле с FK, хранятся полноценные данные, а не ссылки на данные из другой таблици. Просто при вставке нового значения в поле, дергается индекс таблицы на котрую ссылается поле, и производится проверка, есть ли там такое значение.
По поводу ускорения поиска интересный вопрос, но насколько я знаю, сам по себе constraint не дает выйгрышей по производительности и индекс не создает. (Not null может давать, с той точки зрения, что будут строится более оптимальные планы, для некоторых запросов, но сейчас не об этом)
Все вышесказанное относится к бд oracle
>>16275
А. Понятно.
Ты не совсем понимаешь, зачем нужны ФК.
Экономить место на диске - их последняя задача.
Их главная задача не дать тебе насрать в базу.
В твоем примере - не дать тебе написать гИрмания там, где должна бы быть гЕрмания.
Выносить повторяющиеся данные так, чтобы они встречались в своей полноте лишь один раз - опять же не для того, чтобы сэкономить место на диске. Читай про нормальные формы.
А. Понятно.
Ты не совсем понимаешь, зачем нужны ФК.
Экономить место на диске - их последняя задача.
Их главная задача не дать тебе насрать в базу.
В твоем примере - не дать тебе написать гИрмания там, где должна бы быть гЕрмания.
Выносить повторяющиеся данные так, чтобы они встречались в своей полноте лишь один раз - опять же не для того, чтобы сэкономить место на диске. Читай про нормальные формы.
>>16276
Не злой.
Это типичная ошибка начинающих - считать, что ФК дает какую-то связь.
Это приводит ко многим недопониманиям и недоумениям. Я сам через это проходил.
Поэтому, когда непонимающему человеку начинают рассказывать про "связь", я всегда одергиваю.
Не злой.
Это типичная ошибка начинающих - считать, что ФК дает какую-то связь.
Это приводит ко многим недопониманиям и недоумениям. Я сам через это проходил.
Поэтому, когда непонимающему человеку начинают рассказывать про "связь", я всегда одергиваю.
>>16275
Представь, что у тебя есть поле с типом char(1).
Сколько места в записи оно займет?
Теперь представь, что значения из этого поля ты вынес в отдельную таблицу. И сделал ФК на эту таблицу.
Очевидно, что запись будет занимать больше места. Ссылка просто тупо длиннее, чем char(1).
Зато, этим символом ты кодируешь пол (F/M), то используя ФК ты не обосрешься, вставив в запись любой другой символ. ФК нужны именно для этого.
Представь, что у тебя есть поле с типом char(1).
Сколько места в записи оно займет?
Теперь представь, что значения из этого поля ты вынес в отдельную таблицу. И сделал ФК на эту таблицу.
Очевидно, что запись будет занимать больше места. Ссылка просто тупо длиннее, чем char(1).
Зато, этим символом ты кодируешь пол (F/M), то используя ФК ты не обосрешься, вставив в запись любой другой символ. ФК нужны именно для этого.
>>16318
Ну, не обязательно конкретно через ссылки средствами низкоуровневых языков. Может там свои какие-то ухищрения есть под капотом, хер его знает...
Если это действительно так, то все равно есть шанс, что этот индекс окажется гораздо легче дублирования данных.
>>16322
Хорошо, почитаю.
>>16329
Ну, насчет char(1)-то и так понятно. Конечно, не всегда есть смысл использовать ссылки, чьи метаданные весят больше значений на которые они ссылаются, если необходимо в первую очередь сэкономить место.
Меня просто интересует вопрос: как лучше организовывать таблицы в тех или иных случаях, чтобы БД в итоге не весила в 5 раз больше, когда могла весить в 5 раз меньше и при этом оставаться удобной в использовании.
Попробую привести пример того, чего я хочу понять о построении БД. Это касается "вложенных" данных, т.е. когда "что-то" может содержать в себе десяток "чего-то", а то в свою очередь сотню "другого". И получается такая ситуация, например:
Пусть есть таблицы
1. Таблица "производители автомобилей (id, name)", id - PK;
2. Таблица "филиалы производителей (id, id_произ_авто, name)", id - PK, id_произ_авто - FK;
3. Таблица "автомобили (id, id_произ_авто, id_филиал, name)", id - PK, id_произ_авто - FK, id_филиал - FK.
Т.е. есть производитель авто (ferrari), у этого производителя есть много своих салонов для продажи (филиалы), в каждом филиале есть N моделей. Теперь заполним данными эти таблицы:
1. Производители автомобилей
id(1) name(ferrari) 2
id(2) name(nissan)
id(3) name(lexus)
2. Филиалы производителей
id(10) id_произ_авто(1) name(ferrari shop 1)
id(11) id_произ_авто(1) name(ferrari shop 2)
id(12) id_произ_авто(1) name(ferrari shop 3) 12
id(13) id_произ_авто(1) name(ferrari shop 4)
id(14) id_произ_авто(2) name(nissan shop 1)
id(15) id_произ_авто(2) name(nissan shop 2)
id(16) id_произ_авто(3) name(lexus shop 1)
id(17) id_произ_авто(3) name(lexus shop 2)
3. Автомобили
id(100) id_произ_авто(1) id_филиал(10) name(ferrari auto 1)
id(101) id_произ_авто(1) id_филиал(10) name(ferrari auto 2)
id(102) id_произ_авто(1) id_филиал(10) name(ferrari auto 3)
id(103) id_произ_авто(1) id_филиал(10) name(ferrari auto 7)
id(104) id_произ_авто(1) id_филиал(11) name(ferrari auto 1)
id(105) id_произ_авто(1) id_филиал(11) name(ferrari auto 3)
id(106) id_произ_авто(1) id_филиал(12) name(ferrari auto 3)
id(107) id_произ_авто(1) id_филиал(12) name(ferrari auto 5)
id(108) id_произ_авто(1) id_филиал(13) name(ferrari auto 8)
... и т.д.
Из-за подобной структуры, если я правильно понял, с каждой последующей таблицей размер БД будет разрастаться с геометрической прогрессией. И получаем, что только для производителя (ferrari) будет будет отведено 50 байт (представим, что все поля во всех таблицах занимают по 1 байт каждое). Но! Если бы мы отказались от 3 таблицы "автомобили" и вместо нее расширили бы 2 таблицу "филиалы", добавив 4 поля: model_1, model_2, model_3, model_4 (я выбрал 4 по наибольшему ассортименту среди всех филиалов), то итоговый размер для информации о производителе (ferrari) был бы уже не 50 байт, а 42 байта. Это еще при том условии, что 7 полей в этой таблице для (ferrari) не будет заполнено, но я не знаю: занимают ли незаполненные поля какое-то мест оили нет.
Конечно, второй подход для данного примера крайне херовый, ибо кол-во автомобилей будет всегда меняться и для этого придется либо добавлять новые поля, либо брать сразу с запасом. Но факт остается фактом: в одном случае - БД практичная, но занимает больше места; во втором - БД не практична, занимает меньше веса.
Напомню еще раз суть вопроса: как понимать, когда и какой из этих случаев лучше? Или я вовсе не так представляю хранение в БД?
>Сильно сомневаюсь, что есть базы с реализацией fk через ссылки. Как минимум это выльется в массовый апдейт при удалении fk.
Ну, не обязательно конкретно через ссылки средствами низкоуровневых языков. Может там свои какие-то ухищрения есть под капотом, хер его знает...
>Просто при вставке нового значения в поле, дергается индекс таблицы на котрую ссылается поле, и производится проверка, есть ли там такое значение.
Если это действительно так, то все равно есть шанс, что этот индекс окажется гораздо легче дублирования данных.
>>16322
>Читай про нормальные формы.
Хорошо, почитаю.
>>16329
Ну, насчет char(1)-то и так понятно. Конечно, не всегда есть смысл использовать ссылки, чьи метаданные весят больше значений на которые они ссылаются, если необходимо в первую очередь сэкономить место.
Меня просто интересует вопрос: как лучше организовывать таблицы в тех или иных случаях, чтобы БД в итоге не весила в 5 раз больше, когда могла весить в 5 раз меньше и при этом оставаться удобной в использовании.
Попробую привести пример того, чего я хочу понять о построении БД. Это касается "вложенных" данных, т.е. когда "что-то" может содержать в себе десяток "чего-то", а то в свою очередь сотню "другого". И получается такая ситуация, например:
Пусть есть таблицы
1. Таблица "производители автомобилей (id, name)", id - PK;
2. Таблица "филиалы производителей (id, id_произ_авто, name)", id - PK, id_произ_авто - FK;
3. Таблица "автомобили (id, id_произ_авто, id_филиал, name)", id - PK, id_произ_авто - FK, id_филиал - FK.
Т.е. есть производитель авто (ferrari), у этого производителя есть много своих салонов для продажи (филиалы), в каждом филиале есть N моделей. Теперь заполним данными эти таблицы:
1. Производители автомобилей
id(1) name(ferrari) 2
id(2) name(nissan)
id(3) name(lexus)
2. Филиалы производителей
id(10) id_произ_авто(1) name(ferrari shop 1)
id(11) id_произ_авто(1) name(ferrari shop 2)
id(12) id_произ_авто(1) name(ferrari shop 3) 12
id(13) id_произ_авто(1) name(ferrari shop 4)
id(14) id_произ_авто(2) name(nissan shop 1)
id(15) id_произ_авто(2) name(nissan shop 2)
id(16) id_произ_авто(3) name(lexus shop 1)
id(17) id_произ_авто(3) name(lexus shop 2)
3. Автомобили
id(100) id_произ_авто(1) id_филиал(10) name(ferrari auto 1)
id(101) id_произ_авто(1) id_филиал(10) name(ferrari auto 2)
id(102) id_произ_авто(1) id_филиал(10) name(ferrari auto 3)
id(103) id_произ_авто(1) id_филиал(10) name(ferrari auto 7)
id(104) id_произ_авто(1) id_филиал(11) name(ferrari auto 1)
id(105) id_произ_авто(1) id_филиал(11) name(ferrari auto 3)
id(106) id_произ_авто(1) id_филиал(12) name(ferrari auto 3)
id(107) id_произ_авто(1) id_филиал(12) name(ferrari auto 5)
id(108) id_произ_авто(1) id_филиал(13) name(ferrari auto 8)
... и т.д.
Из-за подобной структуры, если я правильно понял, с каждой последующей таблицей размер БД будет разрастаться с геометрической прогрессией. И получаем, что только для производителя (ferrari) будет будет отведено 50 байт (представим, что все поля во всех таблицах занимают по 1 байт каждое). Но! Если бы мы отказались от 3 таблицы "автомобили" и вместо нее расширили бы 2 таблицу "филиалы", добавив 4 поля: model_1, model_2, model_3, model_4 (я выбрал 4 по наибольшему ассортименту среди всех филиалов), то итоговый размер для информации о производителе (ferrari) был бы уже не 50 байт, а 42 байта. Это еще при том условии, что 7 полей в этой таблице для (ferrari) не будет заполнено, но я не знаю: занимают ли незаполненные поля какое-то мест оили нет.
Конечно, второй подход для данного примера крайне херовый, ибо кол-во автомобилей будет всегда меняться и для этого придется либо добавлять новые поля, либо брать сразу с запасом. Но факт остается фактом: в одном случае - БД практичная, но занимает больше места; во втором - БД не практична, занимает меньше веса.
Напомню еще раз суть вопроса: как понимать, когда и какой из этих случаев лучше? Или я вовсе не так представляю хранение в БД?
>>16318
Ну, не обязательно конкретно через ссылки средствами низкоуровневых языков. Может там свои какие-то ухищрения есть под капотом, хер его знает...
Если это действительно так, то все равно есть шанс, что этот индекс окажется гораздо легче дублирования данных.
>>16322
Хорошо, почитаю.
>>16329
Ну, насчет char(1)-то и так понятно. Конечно, не всегда есть смысл использовать ссылки, чьи метаданные весят больше значений на которые они ссылаются, если необходимо в первую очередь сэкономить место.
Меня просто интересует вопрос: как лучше организовывать таблицы в тех или иных случаях, чтобы БД в итоге не весила в 5 раз больше, когда могла весить в 5 раз меньше и при этом оставаться удобной в использовании.
Попробую привести пример того, чего я хочу понять о построении БД. Это касается "вложенных" данных, т.е. когда "что-то" может содержать в себе десяток "чего-то", а то в свою очередь сотню "другого". И получается такая ситуация, например:
Пусть есть таблицы
1. Таблица "производители автомобилей (id, name)", id - PK;
2. Таблица "филиалы производителей (id, id_произ_авто, name)", id - PK, id_произ_авто - FK;
3. Таблица "автомобили (id, id_произ_авто, id_филиал, name)", id - PK, id_произ_авто - FK, id_филиал - FK.
Т.е. есть производитель авто (ferrari), у этого производителя есть много своих салонов для продажи (филиалы), в каждом филиале есть N моделей. Теперь заполним данными эти таблицы:
1. Производители автомобилей
id(1) name(ferrari) 2
id(2) name(nissan)
id(3) name(lexus)
2. Филиалы производителей
id(10) id_произ_авто(1) name(ferrari shop 1)
id(11) id_произ_авто(1) name(ferrari shop 2)
id(12) id_произ_авто(1) name(ferrari shop 3) 12
id(13) id_произ_авто(1) name(ferrari shop 4)
id(14) id_произ_авто(2) name(nissan shop 1)
id(15) id_произ_авто(2) name(nissan shop 2)
id(16) id_произ_авто(3) name(lexus shop 1)
id(17) id_произ_авто(3) name(lexus shop 2)
3. Автомобили
id(100) id_произ_авто(1) id_филиал(10) name(ferrari auto 1)
id(101) id_произ_авто(1) id_филиал(10) name(ferrari auto 2)
id(102) id_произ_авто(1) id_филиал(10) name(ferrari auto 3)
id(103) id_произ_авто(1) id_филиал(10) name(ferrari auto 7)
id(104) id_произ_авто(1) id_филиал(11) name(ferrari auto 1)
id(105) id_произ_авто(1) id_филиал(11) name(ferrari auto 3)
id(106) id_произ_авто(1) id_филиал(12) name(ferrari auto 3)
id(107) id_произ_авто(1) id_филиал(12) name(ferrari auto 5)
id(108) id_произ_авто(1) id_филиал(13) name(ferrari auto 8)
... и т.д.
Из-за подобной структуры, если я правильно понял, с каждой последующей таблицей размер БД будет разрастаться с геометрической прогрессией. И получаем, что только для производителя (ferrari) будет будет отведено 50 байт (представим, что все поля во всех таблицах занимают по 1 байт каждое). Но! Если бы мы отказались от 3 таблицы "автомобили" и вместо нее расширили бы 2 таблицу "филиалы", добавив 4 поля: model_1, model_2, model_3, model_4 (я выбрал 4 по наибольшему ассортименту среди всех филиалов), то итоговый размер для информации о производителе (ferrari) был бы уже не 50 байт, а 42 байта. Это еще при том условии, что 7 полей в этой таблице для (ferrari) не будет заполнено, но я не знаю: занимают ли незаполненные поля какое-то мест оили нет.
Конечно, второй подход для данного примера крайне херовый, ибо кол-во автомобилей будет всегда меняться и для этого придется либо добавлять новые поля, либо брать сразу с запасом. Но факт остается фактом: в одном случае - БД практичная, но занимает больше места; во втором - БД не практична, занимает меньше веса.
Напомню еще раз суть вопроса: как понимать, когда и какой из этих случаев лучше? Или я вовсе не так представляю хранение в БД?
>Сильно сомневаюсь, что есть базы с реализацией fk через ссылки. Как минимум это выльется в массовый апдейт при удалении fk.
Ну, не обязательно конкретно через ссылки средствами низкоуровневых языков. Может там свои какие-то ухищрения есть под капотом, хер его знает...
>Просто при вставке нового значения в поле, дергается индекс таблицы на котрую ссылается поле, и производится проверка, есть ли там такое значение.
Если это действительно так, то все равно есть шанс, что этот индекс окажется гораздо легче дублирования данных.
>>16322
>Читай про нормальные формы.
Хорошо, почитаю.
>>16329
Ну, насчет char(1)-то и так понятно. Конечно, не всегда есть смысл использовать ссылки, чьи метаданные весят больше значений на которые они ссылаются, если необходимо в первую очередь сэкономить место.
Меня просто интересует вопрос: как лучше организовывать таблицы в тех или иных случаях, чтобы БД в итоге не весила в 5 раз больше, когда могла весить в 5 раз меньше и при этом оставаться удобной в использовании.
Попробую привести пример того, чего я хочу понять о построении БД. Это касается "вложенных" данных, т.е. когда "что-то" может содержать в себе десяток "чего-то", а то в свою очередь сотню "другого". И получается такая ситуация, например:
Пусть есть таблицы
1. Таблица "производители автомобилей (id, name)", id - PK;
2. Таблица "филиалы производителей (id, id_произ_авто, name)", id - PK, id_произ_авто - FK;
3. Таблица "автомобили (id, id_произ_авто, id_филиал, name)", id - PK, id_произ_авто - FK, id_филиал - FK.
Т.е. есть производитель авто (ferrari), у этого производителя есть много своих салонов для продажи (филиалы), в каждом филиале есть N моделей. Теперь заполним данными эти таблицы:
1. Производители автомобилей
id(1) name(ferrari) 2
id(2) name(nissan)
id(3) name(lexus)
2. Филиалы производителей
id(10) id_произ_авто(1) name(ferrari shop 1)
id(11) id_произ_авто(1) name(ferrari shop 2)
id(12) id_произ_авто(1) name(ferrari shop 3) 12
id(13) id_произ_авто(1) name(ferrari shop 4)
id(14) id_произ_авто(2) name(nissan shop 1)
id(15) id_произ_авто(2) name(nissan shop 2)
id(16) id_произ_авто(3) name(lexus shop 1)
id(17) id_произ_авто(3) name(lexus shop 2)
3. Автомобили
id(100) id_произ_авто(1) id_филиал(10) name(ferrari auto 1)
id(101) id_произ_авто(1) id_филиал(10) name(ferrari auto 2)
id(102) id_произ_авто(1) id_филиал(10) name(ferrari auto 3)
id(103) id_произ_авто(1) id_филиал(10) name(ferrari auto 7)
id(104) id_произ_авто(1) id_филиал(11) name(ferrari auto 1)
id(105) id_произ_авто(1) id_филиал(11) name(ferrari auto 3)
id(106) id_произ_авто(1) id_филиал(12) name(ferrari auto 3)
id(107) id_произ_авто(1) id_филиал(12) name(ferrari auto 5)
id(108) id_произ_авто(1) id_филиал(13) name(ferrari auto 8)
... и т.д.
Из-за подобной структуры, если я правильно понял, с каждой последующей таблицей размер БД будет разрастаться с геометрической прогрессией. И получаем, что только для производителя (ferrari) будет будет отведено 50 байт (представим, что все поля во всех таблицах занимают по 1 байт каждое). Но! Если бы мы отказались от 3 таблицы "автомобили" и вместо нее расширили бы 2 таблицу "филиалы", добавив 4 поля: model_1, model_2, model_3, model_4 (я выбрал 4 по наибольшему ассортименту среди всех филиалов), то итоговый размер для информации о производителе (ferrari) был бы уже не 50 байт, а 42 байта. Это еще при том условии, что 7 полей в этой таблице для (ferrari) не будет заполнено, но я не знаю: занимают ли незаполненные поля какое-то мест оили нет.
Конечно, второй подход для данного примера крайне херовый, ибо кол-во автомобилей будет всегда меняться и для этого придется либо добавлять новые поля, либо брать сразу с запасом. Но факт остается фактом: в одном случае - БД практичная, но занимает больше места; во втором - БД не практична, занимает меньше веса.
Напомню еще раз суть вопроса: как понимать, когда и какой из этих случаев лучше? Или я вовсе не так представляю хранение в БД?
>>16390
id(1) name(ferrari)
id(12) id_произ_авто(1) name(ferrari shop 3)
фикс
>id(1) name(ferrari) 2
id(1) name(ferrari)
>id(12) id_произ_авто(1) name(ferrari shop 3) 12
id(12) id_произ_авто(1) name(ferrari shop 3)
фикс
>>16413
Уточню, есть база с которой работаем, и где нужно все БЫСТРО, она и пухнет, а есть всякие хранилища данных, в которых хранят и БЫСТРО им не нужно, во втором случае собирают все обратно в огромные таблицы, т.е. денормализуют. Все зависит от задачи.
Уточню, есть база с которой работаем, и где нужно все БЫСТРО, она и пухнет, а есть всякие хранилища данных, в которых хранят и БЫСТРО им не нужно, во втором случае собирают все обратно в огромные таблицы, т.е. денормализуют. Все зависит от задачи.
>>16413
Нет. На данный момент ее еще даже нету. Я не пекусь, просто, если есть возможность уменьшить потенциальный размер БД в 5/10/20... раз, то почему бы и нет? Я не отношусь к ентерпрайзу какому-то. Просто пишу сервер на js для себя, который работал бы с этой БД для своих нужд. Если я могу выделить 5-10 гб для нее на своем диске, то как с этим будут обстоять дела с бесплатными хостингами - хз. У них наверняка будет ограничение на какие-нибудь 500мб.
Нет. На данный момент ее еще даже нету. Я не пекусь, просто, если есть возможность уменьшить потенциальный размер БД в 5/10/20... раз, то почему бы и нет? Я не отношусь к ентерпрайзу какому-то. Просто пишу сервер на js для себя, который работал бы с этой БД для своих нужд. Если я могу выделить 5-10 гб для нее на своем диске, то как с этим будут обстоять дела с бесплатными хостингами - хз. У них наверняка будет ограничение на какие-нибудь 500мб.
>>16390
Как минимум у тебя лишняя ссылка на производителя автомобилей в третьей таблице. Ты ее можешь получить из второй таблицы. Это в нормальных формах описано, как избежать дублирования связок.
Тот оверхед, который ты получаешь при "дублировании" ключевых колонок, в реальных базах не значителен, по отношеню ко всему объему данных. Им пренебрегают. Правда не очень понял, где ты геометрическую прогрессию нашел.
Данные хранятся в таблицах, и то - что ты называешь "дублированием" не решается с помощью ссылок на данные из другой таблицы. "Как-то там под капотом" , за счет fk. Fk - это ограничение, констрэйнт, его цель ограничивать допустимый набор данных.
Как минимум у тебя лишняя ссылка на производителя автомобилей в третьей таблице. Ты ее можешь получить из второй таблицы. Это в нормальных формах описано, как избежать дублирования связок.
Тот оверхед, который ты получаешь при "дублировании" ключевых колонок, в реальных базах не значителен, по отношеню ко всему объему данных. Им пренебрегают. Правда не очень понял, где ты геометрическую прогрессию нашел.
Данные хранятся в таблицах, и то - что ты называешь "дублированием" не решается с помощью ссылок на данные из другой таблицы. "Как-то там под капотом" , за счет fk. Fk - это ограничение, констрэйнт, его цель ограничивать допустимый набор данных.
118 Кб, 750x1328>>16252
Откуда вы лезете пидоры, даже на ебнном мейлаче умудряетесь обьянсять как дед-препод в пту. Унтермеши косноязычные.
Откуда вы лезете пидоры, даже на ебнном мейлаче умудряетесь обьянсять как дед-препод в пту. Унтермеши косноязычные.
>>16419
Я не проводил расчетов никаких, просто прикинул примерно график роста размера БД. Одно ясно точно: график будет с каждой таблицей все круче-и-круче.
С помощью вложенного запроса? Опять же, не знаю как на такое СУБД реагирует. Если это сказывается сильно на производительности, то может и есть смысл, чтобы дублировать ссылки?
В том-то и проблема, что все зависит от вида данных. Если это сотня матрешек, то в таких случаях, я думаю, основной объем БД и будут составлять эти PK и FK. Но сейчас думаю: если в каждой последующей таблице будет только один FK, с помощью которого можно обратиться к любой из предыдущих таблиц, то, наверное, эти FK действительно не так значительны...
>Правда не очень понял, где ты геометрическую прогрессию нашел.
Я не проводил расчетов никаких, просто прикинул примерно график роста размера БД. Одно ясно точно: график будет с каждой таблицей все круче-и-круче.
>Ты ее можешь получить из второй таблицы.
С помощью вложенного запроса? Опять же, не знаю как на такое СУБД реагирует. Если это сказывается сильно на производительности, то может и есть смысл, чтобы дублировать ссылки?
>Тот оверхед, который ты получаешь при "дублировании" ключевых колонок, в реальных базах не значителен
В том-то и проблема, что все зависит от вида данных. Если это сотня матрешек, то в таких случаях, я думаю, основной объем БД и будут составлять эти PK и FK. Но сейчас думаю: если в каждой последующей таблице будет только один FK, с помощью которого можно обратиться к любой из предыдущих таблиц, то, наверное, эти FK действительно не так значительны...
>>16440
Покури про нормализацию, вот этот неплохо рассказывает
https://www.youtube.com/watch?v=1GWx5CZdSCg
Покури про нормализацию, вот этот неплохо рассказывает
https://www.youtube.com/watch?v=1GWx5CZdSCg
>>16390
Забудь об этом.
Вообще забудь.
БД (по крайней мере, реляционная) это не про размер.
А про целостность и доступных данных.
Внешние ключи именно про это.
> как лучше организовывать таблицы в тех или иных случаях, чтобы БД в итоге не весила в 5 раз больше
Забудь об этом.
Вообще забудь.
БД (по крайней мере, реляционная) это не про размер.
А про целостность и доступных данных.
Внешние ключи именно про это.
>>16421
Прости, малыш.
Ты пришел в тред про БД, а не про пуляние козявками.
Тебе сюда: https://2ch.hk/pr/res/1511559.html (
М)
Прости, малыш.
Ты пришел в тред про БД, а не про пуляние козявками.
Тебе сюда: https://2ch.hk/pr/res/1511559.html (
М)>>16493
Нет, ты просто уебок безмозглый, на трубе есть люди которые ВНЕЗАПНО могут рассказать доступно, в отличии от тебя. Значит дело не в бабине.
Нет, ты просто уебок безмозглый, на трубе есть люди которые ВНЕЗАПНО могут рассказать доступно, в отличии от тебя. Значит дело не в бабине.
>>16502
Всем похуй тащемта, в продакшен тебя не кто не пустить без опыта, да ещё на удаленку, так что можешь пока разрабатывать только анус.
Всем похуй тащемта, в продакшен тебя не кто не пустить без опыта, да ещё на удаленку, так что можешь пока разрабатывать только анус.
>>12524
Пидоры блядь ебаные как вы вообще в своих ебаных запросах разбираетесь если даже про самый простейший мыслимый запрос ничего сказать не можете?
Пидоры блядь ебаные как вы вообще в своих ебаных запросах разбираетесь если даже про самый простейший мыслимый запрос ничего сказать не можете?
>>16503
Ахахахахаха
Изучает программирование по видосикам на ютубе
Не умеет в текст
Не понимает, что италиком специально выделена цитата
Бля, спасибо, анончик, пиши еще.
Что бы мы делали без третьеклассников в этом треде?
Ахахахахаха
Изучает программирование по видосикам на ютубе
Не умеет в текст
Не понимает, что италиком специально выделена цитата
>ррряяяяя, вы все мудаки, один я умный, мне на трубе объяснили
Бля, спасибо, анончик, пиши еще.
Что бы мы делали без третьеклассников в этом треде?
>>16558
Не, я как раз тупой, но ты ещё ещё тупее, потому-что тужишься что-то объяснить, но не можешь в объяснение.
Не, я как раз тупой, но ты ещё ещё тупее, потому-что тужишься что-то объяснить, но не можешь в объяснение.
118 Кб, 918x578ньюфаг в треде, есть какая-нибудь годная книжка или ресурс чтобы понять че такое субд как они устроены, откуда там какие то таблички высираются, как это все хранится в памяти в каких структурах? Но чтобы не погрязнуть во всем этом а быстро освоить, сам я с бд имею мало опыта, за жизнь вроде только несколько запросов написал на скюле и с хибернейтом чето из бд вытаскивал в джаве. Но умею в системное программирование ассемблер все такое, знаю на базовом уровне cs.
>>16582
Ахахахаха.
Зумер влез в чужой разговор, ни хуя не понял, закатил истерику.
Классика.
Если бы я собирался что-либо объяснять тебе, конечно, я бы объяснял на примере пчелок и бабочек. Но я не твой учитель информатики, мне на тебя насрать.
Я отвечал конкретному анону, который все, что ему надо, понял.
Когда ты вырастешь, может быть, ты научишься понимать определения из учебников. А пока, иди на хуй, давай, до свидания.
Ахахахаха.
Зумер влез в чужой разговор, ни хуя не понял, закатил истерику.
Классика.
Если бы я собирался что-либо объяснять тебе, конечно, я бы объяснял на примере пчелок и бабочек. Но я не твой учитель информатики, мне на тебя насрать.
Я отвечал конкретному анону, который все, что ему надо, понял.
Когда ты вырастешь, может быть, ты научишься понимать определения из учебников. А пока, иди на хуй, давай, до свидания.
>>16589
"системное программирование" это маркер уебана
никто не знает, что это такое, но каждый уебан думает, что это что-то невъебенно крутое
с другой стороны, нет ничего необычайного в том, что кто-то, имеющий опыт ООП программирования, не сразу въезжает в функциональное, или в реляционную алгебру.
Это вещи идущие параллельными курсами, хули ты бугуртишь-то?
"системное программирование" это маркер уебана
никто не знает, что это такое, но каждый уебан думает, что это что-то невъебенно крутое
с другой стороны, нет ничего необычайного в том, что кто-то, имеющий опыт ООП программирования, не сразу въезжает в функциональное, или в реляционную алгебру.
Это вещи идущие параллельными курсами, хули ты бугуртишь-то?
>>16615
Зумер хотел услышать, что ему незамедлительно сделают приятно.
А когда не услышал, подорвался жопой.
И высрал единственное слово, которое выучил за последние два года.
>Токсичная
Зумер хотел услышать, что ему незамедлительно сделают приятно.
А когда не услышал, подорвался жопой.
И высрал единственное слово, которое выучил за последние два года.
>>16625
Ох блять плесенью потянуло, сьеби в свой совок пенсия, по твоим книжкам 70 года выпуска с зашоренными определениями уже никто не учится. Читни что-нибудь свежеее, и удивишься, что люди ВНЕЗАПНО могут доступно объяснять сложные моменты, а не просто срать цитатами из большой советской энцклопедии, и копипастом высирать матан.
Ох блять плесенью потянуло, сьеби в свой совок пенсия, по твоим книжкам 70 года выпуска с зашоренными определениями уже никто не учится. Читни что-нибудь свежеее, и удивишься, что люди ВНЕЗАПНО могут доступно объяснять сложные моменты, а не просто срать цитатами из большой советской энцклопедии, и копипастом высирать матан.
>>16633
Смузихлеб, почему сложно и непонятно тебе, а виноваты в этом окружающие? Слышал что-нибудь про такие слова как полнота и однозначность трактовки?
Смузихлеб, почему сложно и непонятно тебе, а виноваты в этом окружающие? Слышал что-нибудь про такие слова как полнота и однозначность трактовки?
>>16643
Большинство явлений можно описать несколькими способами, и очевидно что какой-то из способов описания будет лучше, а какой-то хуже. Совки не понимают что высирать термины, не всегда оптимальный путь объяснения не ну а чо вон же там в большой совесткой написано, значит это единственный верный способ донести.
Большинство явлений можно описать несколькими способами, и очевидно что какой-то из способов описания будет лучше, а какой-то хуже. Совки не понимают что высирать термины, не всегда оптимальный путь объяснения не ну а чо вон же там в большой совесткой написано, значит это единственный верный способ донести.
>>16628
Ты говоришь, что знаешь ассемблер. Человек, который знает ассемблер - должен знать архитектуру процессоров устройств, под которые пишет код. Я это предполагал в тебе. А это значит, что въехать в архитектуру какой-то субд на ее прикладном уровне - как обоссать 2 пальца такому гику. Я уже молчу, что ты, видимо, еще и поиском пользоваться не умеешь. Вот такое парадоксальное мнение о себе ты у меня вызвал, потому и не понял тебя.
Ты говоришь, что знаешь ассемблер. Человек, который знает ассемблер - должен знать архитектуру процессоров устройств, под которые пишет код. Я это предполагал в тебе. А это значит, что въехать в архитектуру какой-то субд на ее прикладном уровне - как обоссать 2 пальца такому гику. Я уже молчу, что ты, видимо, еще и поиском пользоваться не умеешь. Вот такое парадоксальное мнение о себе ты у меня вызвал, потому и не понял тебя.
>>16657
Какое имеет значение "среди кого"? Ты жопой читаешь? Или хочешь лишний раз выплеснуть своего токсичного омежку наружу? Уебывай давай, мимокрок...
Какое имеет значение "среди кого"? Ты жопой читаешь? Или хочешь лишний раз выплеснуть своего токсичного омежку наружу? Уебывай давай, мимокрок...
>>16440
Ты в принципе рассуждаешь в верном ключе.
Например про подзапросы, конечно это будет дольше, чем просто прочесть из таблицы, будет лишний запрос по индексу.
Важным моментом является то, что ты должен сам определить, в зависимости от задачи, что является приоритетным: место, производительность, потребление ресурсов.
Нет серебрянной пули, которая решит все проблемы, и единственно верный вариант для всех задач связанных с БД
Но чтобы иметь возможность регулировать все эти вещи, тебе нужно знать устройство бд. Рекомендую документацию oracle по query optimization, как минимум. Там описано про способы доступа к данным: по индексу, сканы, про джоины и их типы. Когда этого будет недостаточно, придется лезть в исходники базы. Я использовал postgres, у него открытый исходный код на С.
После нормализации, тебе стоит почитать про денормализацию, и то для чего ее применяют)
Ты в принципе рассуждаешь в верном ключе.
Например про подзапросы, конечно это будет дольше, чем просто прочесть из таблицы, будет лишний запрос по индексу.
Важным моментом является то, что ты должен сам определить, в зависимости от задачи, что является приоритетным: место, производительность, потребление ресурсов.
Нет серебрянной пули, которая решит все проблемы, и единственно верный вариант для всех задач связанных с БД
Но чтобы иметь возможность регулировать все эти вещи, тебе нужно знать устройство бд. Рекомендую документацию oracle по query optimization, как минимум. Там описано про способы доступа к данным: по индексу, сканы, про джоины и их типы. Когда этого будет недостаточно, придется лезть в исходники базы. Я использовал postgres, у него открытый исходный код на С.
После нормализации, тебе стоит почитать про денормализацию, и то для чего ее применяют)
>>16633
Ахахахаха
Школьник никак не успокоится
Да всем похуй, что ты ни хуя не понял
Одной макакой больше, одной меньше, всем насрать
Тебе никто тут ничего не пытается объяснить
Просто забавно наблюдать за твоими прыжками и ужимками
Продолжай
Ахахахаха
Школьник никак не успокоится
Да всем похуй, что ты ни хуя не понял
Одной макакой больше, одной меньше, всем насрать
Тебе никто тут ничего не пытается объяснить
Просто забавно наблюдать за твоими прыжками и ужимками
Продолжай
>>16650
Смотрите, двачер рассказывает, кто ему что должен
Пиздец, опять каникулы, что ли?
>Человек, который знает ассемблер - должен
Смотрите, двачер рассказывает, кто ему что должен
Пиздец, опять каникулы, что ли?
1,1 Мб, 794x798>>16673
Да не рвись ты так пенсия, тебе внуков надо нянчить, а не на желтом сайте сидеть.
Да не рвись ты так пенсия, тебе внуков надо нянчить, а не на желтом сайте сидеть.
Почему общаясь с большинством тех кто в SQL полез и читая их вопросы в интернете, создается впечатление, что в этот самый SQL лезут какие-то отбитые и ленивые люди? Индексы не юзают, строить БД так чтобы можно было отследить изменения во времени не умеют, а если им построят нормальные люди, то написать запрос который отобразит нужные данные в конкретный период времени не смогут и все в таком духе. Сколько вы хоть зарабатываете-то? Уверен, что немало. Так делаете свою работу нормально. Что в этом сложного-то? Выучил как декомпозировать сущность до третьей нормальной формы, научился включать индекирование, включил его для наиболее часто запрашиваемых данных, переодически перестраиваешь индексы, и напиши пару хранимок, которые попросят, чтобы не приходилось какой-то ужас из тащить на сервер, ну и посмотри план выполнения запроса, найду узкие места и подумай как оптимизировать запрос, чтобы не приходилось по всей таблице бегать и искать что ты там найти хочешь, вот все что от большинства из вас надо. Нет, блядь, даже этого сделать не можете.
39 Кб, 500x333>>16691
А нахуя, если и так платят?
А нахуя, если и так платят?
>>16683
Ахахахахаха
ты ни хуя не понимаешь, что в треде написано, а рвусь я
пиздец, у школьников говна в череп налито.
Тебя-то видно, как нянчили, бггг
Ахахахахаха
ты ни хуя не понимаешь, что в треде написано, а рвусь я
пиздец, у школьников говна в череп налито.
Тебя-то видно, как нянчили, бггг
>>16691
чо-чо?
изменения чего во времени?
давай послушаем, как ты версионируешь ERD, может, чего почерпну от умного человека
>строить БД так чтобы можно было отследить изменения во времени не умеют
чо-чо?
изменения чего во времени?
давай послушаем, как ты версионируешь ERD, может, чего почерпну от умного человека
>>16691
Не раскачивай тут лодку, кто-то должен наговнокодить, чтобы за исправление потом хорошо заплатили
Не раскачивай тут лодку, кто-то должен наговнокодить, чтобы за исправление потом хорошо заплатили
>>16706
Ну пропустил кусок про изменение значения какого-то поля. Условно, на простом примере, есть цена на товар. Вот есть тебя есть таблица "Товары", там есть баклажан, сегодня рубль стоит, завтра два, через год три, для анализа может быть полезно иметь информацию сколько стоил это баклажан 2 года назад, может быть мы заметим какую-то закономерность, скажем, что при увеличении цены на баклажаны люди начинают чаще покупать кабачки, а может быть мы поймем что количество проданых баклажанов только от времени года зависит, а может быть это вообще случайная величина, кто знает.
Ты будто меня на чем-то подловить хочешь.
Если ты про проектирование такой вот фигни, то тут довольно подробно описано как такое делается ручками с примерами кода http://www2.cs.arizona.edu/~rts/tdbbook.pdf
Если про готовые, то с MS SQL Server16 умеет из коробки https://docs.microsoft.com/ru-ru/sql/relational-databases/tables/temporal-tables?view=sql-server-ver15
> изменения чего во времени?
Ну пропустил кусок про изменение значения какого-то поля. Условно, на простом примере, есть цена на товар. Вот есть тебя есть таблица "Товары", там есть баклажан, сегодня рубль стоит, завтра два, через год три, для анализа может быть полезно иметь информацию сколько стоил это баклажан 2 года назад, может быть мы заметим какую-то закономерность, скажем, что при увеличении цены на баклажаны люди начинают чаще покупать кабачки, а может быть мы поймем что количество проданых баклажанов только от времени года зависит, а может быть это вообще случайная величина, кто знает.
> давай послушаем, как ты версионируешь ERD, может, чего почерпну от умного человека
Ты будто меня на чем-то подловить хочешь.
Если ты про проектирование такой вот фигни, то тут довольно подробно описано как такое делается ручками с примерами кода http://www2.cs.arizona.edu/~rts/tdbbook.pdf
Если про готовые, то с MS SQL Server16 умеет из коробки https://docs.microsoft.com/ru-ru/sql/relational-databases/tables/temporal-tables?view=sql-server-ver15
>>16709
Не понял, объясни...
Не понял, объясни...
>>16828
Потому-что вопрос ебланский.
Что в твоем понимании атомарная операция? Вопрос показывает полное не понимание принципов ACID.
Что тебя удивляет в том, что нужно перечитавать таблицу? Как тебе написали вышe, это зависит от реализации.
И во многих базах count() по таблице приведет к перечитыванию таблицы, что тут удивительного?
В том отрывке что ты привел используется древнючая версия PG, и там описан нюанс, который решается операцией vacuum, из-за модели поддержания консистентности базы. И к самом count() имеет слабое отношение. И может вылезти на любом запросе.
Все эти вещи очевидны, если имеешь хоть малейшее представление, о внутреннем устройстве базы.
Нихуя не разбираются, ебланские вопросы задают, еще и вякают поьом что-то
Потому-что вопрос ебланский.
Что в твоем понимании атомарная операция? Вопрос показывает полное не понимание принципов ACID.
Что тебя удивляет в том, что нужно перечитавать таблицу? Как тебе написали вышe, это зависит от реализации.
И во многих базах count() по таблице приведет к перечитыванию таблицы, что тут удивительного?
В том отрывке что ты привел используется древнючая версия PG, и там описан нюанс, который решается операцией vacuum, из-за модели поддержания консистентности базы. И к самом count() имеет слабое отношение. И может вылезти на любом запросе.
Все эти вещи очевидны, если имеешь хоть малейшее представление, о внутреннем устройстве базы.
Нихуя не разбираются, ебланские вопросы задают, еще и вякают поьом что-то
>>16828
Там два вопроса.
Ни один не является вопросом про запрос.
Один - вопрос про реализации в разных БД.
Второй - какая-то хуйня на суржике, которую кроме тебя никто не понимает.
Как результат - никому на хуй не сдалось на них отвечать.
Там два вопроса.
Ни один не является вопросом про запрос.
Один - вопрос про реализации в разных БД.
Второй - какая-то хуйня на суржике, которую кроме тебя никто не понимает.
Как результат - никому на хуй не сдалось на них отвечать.
>>16917
То что у одного слова могут быть разные значения в твою тупорылую бошку не лезет? Ясно что подразумевалось не атомарное из ACID, а то что в нормальной реализации количество строк должно храниться в одной переменно и из нее браться, а если есть другие реализации это просто запредельное ебланство. Т.е. я просто хочу узнать сколько строк у меня в таблице и все виснет нахуй / задумывается на несколько минут - вот это заебца придумали. Неужели есть ебнутые думающие что это не супер хуево?
>Что в твоем понимании атомарная операция? Вопрос показывает полное не понимание принципов ACID.
То что у одного слова могут быть разные значения в твою тупорылую бошку не лезет? Ясно что подразумевалось не атомарное из ACID, а то что в нормальной реализации количество строк должно храниться в одной переменно и из нее браться, а если есть другие реализации это просто запредельное ебланство. Т.е. я просто хочу узнать сколько строк у меня в таблице и все виснет нахуй / задумывается на несколько минут - вот это заебца придумали. Неужели есть ебнутые думающие что это не супер хуево?
Алсо, свитеркам покушать принес:
At GitHub we do not use foreign keys, ever, anywhere.
https://github.com/github/gh-ost/issues/331#issuecomment-266027731
At GitHub we do not use foreign keys, ever, anywhere.
https://github.com/github/gh-ost/issues/331#issuecomment-266027731
>>17038
Так возьми и сделай нормальную реализацию, хули ты пиздаболишь тут, еблана кусок. Возьми и напиши свою реляционку, с правильной реализацией, где количество строк хранится в переменной, раз все такие мудаки тупые и до тебя гения не додумались. Так ты усрешься блять.
Дибилоид тупой, я еще угадывать должен, что ты подразумевал из множества значений? Сука, мудак, не можешь вопрос сформулировать нормально, зато критик архитектур и решений нихуевый.
И еще, додик-недоучка, операция чтения переменной, может быть не атомарной, в зависимости от разрядности архитектуры и размера меременной.
Лучше свою энергию на обучение направляй, а не на дешевые выебоны
Так возьми и сделай нормальную реализацию, хули ты пиздаболишь тут, еблана кусок. Возьми и напиши свою реляционку, с правильной реализацией, где количество строк хранится в переменной, раз все такие мудаки тупые и до тебя гения не додумались. Так ты усрешься блять.
Дибилоид тупой, я еще угадывать должен, что ты подразумевал из множества значений? Сука, мудак, не можешь вопрос сформулировать нормально, зато критик архитектур и решений нихуевый.
И еще, додик-недоучка, операция чтения переменной, может быть не атомарной, в зависимости от разрядности архитектуры и размера меременной.
Лучше свою энергию на обучение направляй, а не на дешевые выебоны
>>17038
Так а в чем проблема? Считаешь количество строк сам и записываешь куда тебе надо (тоже сам)
Так а в чем проблема? Считаешь количество строк сам и записываешь куда тебе надо (тоже сам)
>>17042
Так ты не привыкай, а учись нормально формулировать свои глупые мысли.
Так ты не привыкай, а учись нормально формулировать свои глупые мысли.
>>17039
Ахахаха
mysql
Говно рассказывает на дваче про говно говна, приправляю свои шизоидными высерками ебанутой лексикой, которую понимают только его одноклассники.
Классика!
Ахахаха
mysql
Говно рассказывает на дваче про говно говна, приправляю свои шизоидными высерками ебанутой лексикой, которую понимают только его одноклассники.
Классика!
>>17038
Чо-то ни хуя не удивлен, что у таких ебланов проблемы с сиквелом.
>рррряяяяя, я использую слова не так, как все, а вы все мудаки, раз не можете отгадать!
Чо-то ни хуя не удивлен, что у таких ебланов проблемы с сиквелом.
Хочу изучить sql и pl/sql oralce
столкнулся блять с тем что в этой ебанине сукаблять не отображается демонстрационные база HR, для обучения. Не могу блять разобраться интернеты эти ваши, какую то ебанину выдают. Как я понимаю по дефолту они заблочены.
Проделал: "Кнопка Пуск –> Все программы -> Oracle Database 11g Express Edition –> Run SQL Command Line. Подключитесь как пользователь SYSTEM:
Напечатайте connect Введите имя для подключения: SYSTEM Введите пароль: <пароль-для-SYSTEM >
После успешного подключения (сообщения connected) введите следующий SQL-оператор:
SQL> ALTER USER HR ACCOUNT UNLOCK;
Введите пароль для пользователя HR с помощью следующего SQL-оператора:
SQL> ALTER USER HR IDENTIFIED BY HR;
Для выхода из редактора введите SQL-оператор:
SQL> EXIT"
Захожу sql developer и пишу:
"select from HR.employees;"
по итогу нихуя:
ORA-00942: table or view does not exist
00942. 00000 - "table or view does not exist"
Cause:
*Action:
Error at Line: 1 Column: 18
столкнулся блять с тем что в этой ебанине сукаблять не отображается демонстрационные база HR, для обучения. Не могу блять разобраться интернеты эти ваши, какую то ебанину выдают. Как я понимаю по дефолту они заблочены.
Проделал: "Кнопка Пуск –> Все программы -> Oracle Database 11g Express Edition –> Run SQL Command Line. Подключитесь как пользователь SYSTEM:
Напечатайте connect Введите имя для подключения: SYSTEM Введите пароль: <пароль-для-SYSTEM >
После успешного подключения (сообщения connected) введите следующий SQL-оператор:
SQL> ALTER USER HR ACCOUNT UNLOCK;
Введите пароль для пользователя HR с помощью следующего SQL-оператора:
SQL> ALTER USER HR IDENTIFIED BY HR;
Для выхода из редактора введите SQL-оператор:
SQL> EXIT"
Захожу sql developer и пишу:
"select from HR.employees;"
по итогу нихуя:
ORA-00942: table or view does not exist
00942. 00000 - "table or view does not exist"
Cause:
*Action:
Error at Line: 1 Column: 18
>>18005
Так у тебя нет такой базы, откуда ей взяться? Её сначало нужно залить в бд скриптом, или прикрептить через оснатску.
Не лезь блядь дибил сука ебанный
Так у тебя нет такой базы, откуда ей взяться? Её сначало нужно залить в бд скриптом, или прикрептить через оснатску.
Не лезь блядь дибил сука ебанный
>>18048
Тебе русским языком напиали, что речь идет про Оракл, а не про говномускул.
Хули ты лезешь с советами, если даже вопрос прочесть не можешь?
Тебе русским языком напиали, что речь идет про Оракл, а не про говномускул.
Хули ты лезешь с советами, если даже вопрос прочесть не можешь?
>>18005
Зачем ты приходишь на двач, если все подробно расписано у оракла?
https://docs.oracle.com/database/121/COMSC/installation.htm#COMSC001
Зачем ты приходишь на двач, если все подробно расписано у оракла?
https://docs.oracle.com/database/121/COMSC/installation.htm#COMSC001
>>17271
В свитеромирке ничего другого и нет. Или кто то серьезно считает что разработчики с гитхаба тупее местной пидорвы и не взвесили плюсы и минусы делая выбор.
Так же то что любое говно слепленное на коленке вроде монги может ворваться в этот свитеромирок и захватить значимую долю - какбы весьма красноречиво говорит о многом.
>>17272
Так говорят только ебнутые.
Аргумент что так когда то лет пятьдесят он на самом деле назывался и полоумные деды за ебаных пятьдесят лет никак не могут перестроиться и упорно делают вид что так правильно - аргумент ебнутых.
Кстати, отлично демонстрирует уровень умственных способностей свитероблядей.
>говно говна
В свитеромирке ничего другого и нет. Или кто то серьезно считает что разработчики с гитхаба тупее местной пидорвы и не взвесили плюсы и минусы делая выбор.
Так же то что любое говно слепленное на коленке вроде монги может ворваться в этот свитеромирок и захватить значимую долю - какбы весьма красноречиво говорит о многом.
>>17272
>сиквелом
Так говорят только ебнутые.
Аргумент что так когда то лет пятьдесят он на самом деле назывался и полоумные деды за ебаных пятьдесят лет никак не могут перестроиться и упорно делают вид что так правильно - аргумент ебнутых.
Кстати, отлично демонстрирует уровень умственных способностей свитероблядей.
>>18165
Ты ответы через генератор случайных чисел пишешь?
Ты ответы через генератор случайных чисел пишешь?
>>02870 (OP)
Хай двачата, помогите плиз с моим траблом:
Столкнулся с тем, что сайт невозможно редактировать. Кидает страшную ошибку "Software error:...". Оказалось база данных сайта переполнена. С помощью phpmyadmin я оптимизировал таблицы, но результата это не дало. Я полный чайник, искал инфу у гугла, но толковых мануалов не нашёл. Есть две таблицы на 1.5 и 1.3 гига: phpbb3_search_wordmatch и phpbb3_posts. Я нагуглил что первый это что-то связанное с индексом поиска, а второе сообщение на сайте. Как их почистить, есть мануалы?
Хай двачата, помогите плиз с моим траблом:
Столкнулся с тем, что сайт невозможно редактировать. Кидает страшную ошибку "Software error:...". Оказалось база данных сайта переполнена. С помощью phpmyadmin я оптимизировал таблицы, но результата это не дало. Я полный чайник, искал инфу у гугла, но толковых мануалов не нашёл. Есть две таблицы на 1.5 и 1.3 гига: phpbb3_search_wordmatch и phpbb3_posts. Я нагуглил что первый это что-то связанное с индексом поиска, а второе сообщение на сайте. Как их почистить, есть мануалы?
>>18146
под админа (если я правильно понимаю)
При установке, прикл 1 попросил придумать пароль. Потом пошел в прикл 2. Там вылазит прикл 3 вылазит окно, туда соответственно SYSTEM и пароль что вводил на прикл 1 при установке. Потом прикл 4. Там все сделал, ввел все тот же пароль при установке (чтоб мозги не ебать) и по этому всему подрубался через sql developer
под админа (если я правильно понимаю)
При установке, прикл 1 попросил придумать пароль. Потом пошел в прикл 2. Там вылазит прикл 3 вылазит окно, туда соответственно SYSTEM и пароль что вводил на прикл 1 при установке. Потом прикл 4. Там все сделал, ввел все тот же пароль при установке (чтоб мозги не ебать) и по этому всему подрубался через sql developer
>>18434
дебил бляд загугли нахуй
дебил бляд загугли нахуй
68 Кб, 1268x797>>18620
вот тут получилось а через девелепер я хз
вот тут получилось а через девелепер я хз
>>18605
зайди, блядь, юзером HR и перестань нам ебать мозги
в оракле, для нормальных (не сис и систем) юзеров, имя схемы по умолчанию == имени пользователя
чтобы, зайдя одним юзером, смотреть напрямую на другую схему надо сделать
ALTER SESSION SET CURRENT_SCHEMA = <schema name>
CONNECT scott
ALTER SESSION SET CURRENT_SCHEMA = joe;
SELECT * FROM emp;
я что, ебу, что ли, есть ли гранты у system на твой ебучий hr?
раз ты заходишь системом, посмотрел бы сразу, что у тебя там в схеме hr
может, там и впрямь, ни одной таблицы, а пустая схема
зайди, блядь, юзером HR и перестань нам ебать мозги
в оракле, для нормальных (не сис и систем) юзеров, имя схемы по умолчанию == имени пользователя
чтобы, зайдя одним юзером, смотреть напрямую на другую схему надо сделать
ALTER SESSION SET CURRENT_SCHEMA = <schema name>
CONNECT scott
ALTER SESSION SET CURRENT_SCHEMA = joe;
SELECT * FROM emp;
я что, ебу, что ли, есть ли гранты у system на твой ебучий hr?
раз ты заходишь системом, посмотрел бы сразу, что у тебя там в схеме hr
может, там и впрямь, ни одной таблицы, а пустая схема
>>18641
да все блять, через Toad for Oracle получилось, не ебу почему через ссаный девелепер не вышло, но собственно похуй уже на него
да все блять, через Toad for Oracle получилось, не ебу почему через ссаный девелепер не вышло, но собственно похуй уже на него
>>18641
но за ответ спасибо
но за ответ спасибо
>>18479
Bump
Bump
>>18479
Не надо чистить эти таблицы. Ощущение, что они нужндля нормальной работы.
Посмотри лучше, сколько места занимает transaction log.
Не надо чистить эти таблицы. Ощущение, что они нужндля нормальной работы.
Посмотри лучше, сколько места занимает transaction log.
>>18479
Ебааааааааать. Это сколько вы там на форуме напиздели? 1.3 гига текста? Это же опизденеть как дохуя.
>phpbb3_posts
>1.3гига
Ебааааааааать. Это сколько вы там на форуме напиздели? 1.3 гига текста? Это же опизденеть как дохуя.
>>17042
Чувак, ты в каком-нибудь ебучим си-треде так вопрос задай, очередь к твоей матери метров на 10 выстроится.
Чувак, ты в каком-нибудь ебучим си-треде так вопрос задай, очередь к твоей матери метров на 10 выстроится.
>>19778 (Del)
Ты какой-то ебанутый
>кококо, почему вместо того, чтобы пересчитать число оно пересчитывает число?
Ты какой-то ебанутый
>>02870 (OP)
бамперной
бамперной
>>19890
У нее просто owerflow уже
У нее просто owerflow уже
Бля реляционку учить или ноСКЛ сук.
смотрел примеры CRUD в сравнении с муськой и монгой, на SQL показалось логичнее, чем на json
смотрел примеры CRUD в сравнении с муськой и монгой, на SQL показалось логичнее, чем на json
>>20932
Да я бы с радостью в csv файлы писал, но требуют, суки.
Да я бы с радостью в csv файлы писал, но требуют, суки.
>>20904
Азы скл и дальше носкл
Азы скл и дальше носкл
150 Кб, 1698x1131>>02870 (OP)
Сап.
Входные данные: Хороший SQL, нормальный PL/SQL, знаю прилично теорию по проектированию/ нормализации и все вот эти реляционные вещи ( практический опыт тоже есть) Работа тоже с этим связана.
Заканчиваю вузик по Информационной безопасности, хотелось бы как можно больше связать его с БД, но нет ни одного препода на кафедре, кто мог бы помочь с темой, собсна возьмут только если поставлю конкретную тему сам
На ум приходит только разработка-проектирование бд и системы защиты информации и дать права/роли юзерам и зашифровать айдишники, но это больше на курсач максимум тянет, чем на ВКР.
Короч, ПОКИДАЙТЕ ИДЕЙ ДЛЯ ВКР ПО БД + ИБ
Или может почитать чего интересного по этой теме
Сап.
Входные данные: Хороший SQL, нормальный PL/SQL, знаю прилично теорию по проектированию/ нормализации и все вот эти реляционные вещи ( практический опыт тоже есть) Работа тоже с этим связана.
Заканчиваю вузик по Информационной безопасности, хотелось бы как можно больше связать его с БД, но нет ни одного препода на кафедре, кто мог бы помочь с темой, собсна возьмут только если поставлю конкретную тему сам
На ум приходит только разработка-проектирование бд и системы защиты информации и дать права/роли юзерам и зашифровать айдишники, но это больше на курсач максимум тянет, чем на ВКР.
Короч, ПОКИДАЙТЕ ИДЕЙ ДЛЯ ВКР ПО БД + ИБ
Или может почитать чего интересного по этой теме
>>21200
Ты про OlAP ? и чем эта модель больше связана с ИБ чем OLTP?
Мне бы скорее что то по админству СУБД
Ты про OlAP ? и чем эта модель больше связана с ИБ чем OLTP?
Мне бы скорее что то по админству СУБД
>>21219
А тебе прям непременно с ИБ нужно? Ну хз тогда что можно высрать по ИБ, шифрование, политика пользователей+прокси, огнестена, на курсовую не тянет как по мне. Хули там админить, то хуяк, пиздык и в продакшен....Разве что запилить отдельные таблицы аудита и сделать тригеры, ну что-то это всё развлечения уровня ебли осла с табуретки.
А тебе прям непременно с ИБ нужно? Ну хз тогда что можно высрать по ИБ, шифрование, политика пользователей+прокси, огнестена, на курсовую не тянет как по мне. Хули там админить, то хуяк, пиздык и в продакшен....Разве что запилить отдельные таблицы аудита и сделать тригеры, ну что-то это всё развлечения уровня ебли осла с табуретки.
>>21183
Вуз в топе или нет?
Вуз в топе или нет?
37 Кб, 500x442Аноны, а что-нибудь из топовых курсов помимо sql-ex есть? Или его достаточно с головой будет, просто может за это время придумали еще чего поинтереснее.
На sql-ex просто дрочить учебник и решать задачки?
На sql-ex просто дрочить учебник и решать задачки?
>>22683
NoSQL
NoSQL
>>22683
Я вот этого смотрю, хорошо объясняет
https://youtu.be/cRoTc8ONWSQ
Там еще один курс есть. Sqlex сделано совсем уж из говна и палок, у меня глаза от него вытекают.
Я вот этого смотрю, хорошо объясняет
https://youtu.be/cRoTc8ONWSQ
Там еще один курс есть. Sqlex сделано совсем уж из говна и палок, у меня глаза от него вытекают.
Почему в интернете так дохуя курсов про основы, типа SELECT'ов, что такое индекс и как делать джоины, но нихуя толком нет кроме сухих статей про более глубокие вещи типа эксплейнов, хинтов, правильному обслуживанию и выбору индексов итд?
>>22924
Я про то что это вообще такое и как одну таблицу к другой прихуячить
Я про то что это вообще такое и как одну таблицу к другой прихуячить
Помогите найти тему для магистратской работы!
Есть желание замутить что типо бд для хранения изображений/видео/аудио для мамашиного обучения с ETL, но не знаю как сформулировать тему, какие актуальные таски, проблемы, есть в этой области, которые можно решить. Можете что-нибудь порекомендовать? Какую-нибудь статью, которая, к примеру, рассматривает интересные задачи по компьютерному зрению или речевому распознаванию?
Есть желание замутить что типо бд для хранения изображений/видео/аудио для мамашиного обучения с ETL, но не знаю как сформулировать тему, какие актуальные таски, проблемы, есть в этой области, которые можно решить. Можете что-нибудь порекомендовать? Какую-нибудь статью, которая, к примеру, рассматривает интересные задачи по компьютерному зрению или речевому распознаванию?
Аноны, помогите :(
Не могу понять, как смоделировать таблицы с ключами для лекарств и их аналогов, которые являются одним и тем же полем. Пользователю по 1 лекарству можно смотреть множество аналогов.
Не могу понять, как смоделировать таблицы с ключами для лекарств и их аналогов, которые являются одним и тем же полем. Пользователю по 1 лекарству можно смотреть множество аналогов.
>>23155
Твою конечно. Всем тредом её обучаем продвинутой техники горлового минета.
Твою конечно. Всем тредом её обучаем продвинутой техники горлового минета.
13 Кб, 556x822>>23143
Эм, а в чём трабл?
Либо если таблица небольшая, просто все в одну пихать, а потом фильтровать. Либо составной ключ.
Эм, а в чём трабл?
Либо если таблица небольшая, просто все в одну пихать, а потом фильтровать. Либо составной ключ.
>>23143
а нельзя бахнуть одну таблицу для лекарств, просто всем добавить колонку "аналог", которое будет иметь запись ID лекарства в той же таблице, аналогом для которого является это лекарство?
мимо
а нельзя бахнуть одну таблицу для лекарств, просто всем добавить колонку "аналог", которое будет иметь запись ID лекарства в той же таблице, аналогом для которого является это лекарство?
мимо
13 Кб, 692x282>>02870 (OP)
Ребятки-котятки, есть вопрос. В общем, есть такая схема состоящая из 4 таблиц. У нас есть таблицы владельцев, абстрактных животных, котиков, собачек. Котики и собачки являются подмножеством животных, если смотреть в ооп, то они наследуются от класса животных. Так вот, собственно говоря вопрос, как на уровне бд ограничить у одного владельца котов одного цвета. Если бы в таблице cats был бы owner_id, то я просто бы сделал составной уникальный индекс из полей owner_id и color, но owner_id доступен только в связанной таблице animals. Как решить этот вопрос? Либо я говно у меня архитектура говно (если так, предложите что нибудь лучше), либо можно как то сделать составной индекс с полями из связанных таблиц, а я и не знаю?
Ребятки-котятки, есть вопрос. В общем, есть такая схема состоящая из 4 таблиц. У нас есть таблицы владельцев, абстрактных животных, котиков, собачек. Котики и собачки являются подмножеством животных, если смотреть в ооп, то они наследуются от класса животных. Так вот, собственно говоря вопрос, как на уровне бд ограничить у одного владельца котов одного цвета. Если бы в таблице cats был бы owner_id, то я просто бы сделал составной уникальный индекс из полей owner_id и color, но owner_id доступен только в связанной таблице animals. Как решить этот вопрос? Либо я говно у меня архитектура говно (если так, предложите что нибудь лучше), либо можно как то сделать составной индекс с полями из связанных таблиц, а я и не знаю?
Стоит ли использовать ORM, если в базе данных и не пахло ни какими нормальными формами? Стоит ли пердолиться и настраивать классы, которые кое-как сгенерит маппер? Или проще просто сделать вручную нужные классы для нужных сущностей, которые предполагается дёргать из базы и вручную запилить в этих классах обращения к sql серверу?
База чужая, оптимизировать её нельзя.
Что посоветуете?
База чужая, оптимизировать её нельзя.
Что посоветуете?
>>23872
Что если цвета и породы вынести в отдельные таблицы, а потом сделать составной ключ, как советуют тут: https://stackoverflow.com/questions/5835978/how-to-properly-create-composite-primary-keys-mysql устроит такое решение?
Что если цвета и породы вынести в отдельные таблицы, а потом сделать составной ключ, как советуют тут: https://stackoverflow.com/questions/5835978/how-to-properly-create-composite-primary-keys-mysql устроит такое решение?
>>05350
ну все же может поздно, но стоит упомянуть что threads это отдельная таблица, привязанная к постуно не важно.
я нашел куда удобнее вариант чем то что ты написал, а именно select posts where in (select id from threads limit ?) -> сортировка на стороне сервера (не дб)
ну все же может поздно, но стоит упомянуть что threads это отдельная таблица, привязанная к постуно не важно.
я нашел куда удобнее вариант чем то что ты написал, а именно select posts where in (select id from threads limit ?) -> сортировка на стороне сервера (не дб)
>>24161
Дык в русской википедии есть статья про схему звезда. Или тебе не это нужно? Или там не понятно?
Дык в русской википедии есть статья про схему звезда. Или тебе не это нужно? Или там не понятно?
>>24205
Хм, и правда есть, спс. Чуть подробней бы.
Хм, и правда есть, спс. Чуть подробней бы.
>>23876
Что-что.
Попробовать воспользоваться orm, если fk все есть, и посмотреть через профайлер, какие запросы орм генерирует. Если калл, то ебашь сам руками.
Что-что.
Попробовать воспользоваться orm, если fk все есть, и посмотреть через профайлер, какие запросы орм генерирует. Если калл, то ебашь сам руками.
290 Кб, 2048x1536>>21202
Что ты подразумевешь под звездообразным джойном?
Такое даже не гуглится, блжад.
Что это?
Cross join?
Организация основной таблички типом «звезда», чтобы потом джойнить справочники только на нее?
Что ты подразумевешь под звездообразным джойном?
Такое даже не гуглится, блжад.
Что это?
Cross join?
Организация основной таблички типом «звезда», чтобы потом джойнить справочники только на нее?
>>24358
Нету fk. Вообще нет ни одного. Хотя в таблицах есть поля типа table1_id которые по задумке автора ссылаются на примари ключ id таблицы table1, но самого ключа нет и создать его нельзя. Если я буду юзать orm, то это получается что мне всегда нужно будет аккуратно программировать хули там эта орм сохраняет и обновляет, чтобы база по пизде не пошла. Вот и думаю, может ну его, написать просто классы модели вручную и вручную закодить там загрузку и сохранение в базу.
Нету fk. Вообще нет ни одного. Хотя в таблицах есть поля типа table1_id которые по задумке автора ссылаются на примари ключ id таблицы table1, но самого ключа нет и создать его нельзя. Если я буду юзать orm, то это получается что мне всегда нужно будет аккуратно программировать хули там эта орм сохраняет и обновляет, чтобы база по пизде не пошла. Вот и думаю, может ну его, написать просто классы модели вручную и вручную закодить там загрузку и сохранение в базу.
>>24530
Извини, не сразу дошло, что у тебя в названии препарата могут и аналоги быть
Извини, не сразу дошло, что у тебя в названии препарата могут и аналоги быть
Народ,хелп:
Найти производителей, которые выпускают более одной модели, при этом все выпускаемые производителем модели являются продуктами одного типа.
Вывести: maker, type
Схема БД: http://www.sql-ex.ru/help/select13.php#db_1
http://www.sql-ex.ru/learn_exercises.php#answer_ref
Мой солюшн:
SELECT maker,type FROM Product
WHERE maker =(SELECT maker FROM Product
group by maker
HAVING COUNT (distinct type) =1
AND COUNT (model)>1
)
group by maker,type
ПОд ответ подгоняется, на проверочной базе фейлит.
Найти производителей, которые выпускают более одной модели, при этом все выпускаемые производителем модели являются продуктами одного типа.
Вывести: maker, type
Схема БД: http://www.sql-ex.ru/help/select13.php#db_1
http://www.sql-ex.ru/learn_exercises.php#answer_ref
Мой солюшн:
SELECT maker,type FROM Product
WHERE maker =(SELECT maker FROM Product
group by maker
HAVING COUNT (distinct type) =1
AND COUNT (model)>1
)
group by maker,type
ПОд ответ подгоняется, на проверочной базе фейлит.
>>24767
За такое кривое форматирование, тебе нужно руки поломать, чтоб ты никогда больше не писал ничего.
За такое кривое форматирование, тебе нужно руки поломать, чтоб ты никогда больше не писал ничего.
>>24406
Если у тебя нет fk, не совсем понимаю, как орм будет работать, если только ты там где-то в конфигураторе пропишешь это. entity Framework, например, так не умеет, насколько я знаю.
Если у тебя нет fk, не совсем понимаю, как орм будет работать, если только ты там где-то в конфигураторе пропишешь это. entity Framework, например, так не умеет, насколько я знаю.
>>24781
Да ты зайка)
Да ты зайка)
>>04513
Там может быть какой-нибудь NFS и из за этого оно будет тормозить.
Там может быть какой-нибудь NFS и из за этого оно будет тормозить.
>>24054
Ни хуя не понял, но рад за тебя.
Ни хуя не понял, но рад за тебя.
52 Кб, 1599x251Как сделать так чтобы выводилась только вторая запись? Можно ли как-то сделать метод IN строгим, чтобы он выбирал из тех записей, которые строго соответствуют заданным параметрам?
>>26259
Мне нужно вывести запись второго типа то есть: чтобы там были параметры и 'lorefriendly' и 'big', а он выводит вообще все подряд, где встречаются это параметры. Как это можно реализовать при связи многие ко многим? Пытался через AND перечислять, так он никакие не выводит.
Мне нужно вывести запись второго типа то есть: чтобы там были параметры и 'lorefriendly' и 'big', а он выводит вообще все подряд, где встречаются это параметры. Как это можно реализовать при связи многие ко многим? Пытался через AND перечислять, так он никакие не выводит.
>>26321
Заджойни по олдскулу и расставь скобки, как-то так.
select * from t1,t2,t3 where (t1.zalupa = t2.zalupa_id and t1.huita = t3.huita_id) and t1.tag in('tag1', 'tag2');
Заджойни по олдскулу и расставь скобки, как-то так.
select * from t1,t2,t3 where (t1.zalupa = t2.zalupa_id and t1.huita = t3.huita_id) and t1.tag in('tag1', 'tag2');
>>24362
Это.
Ну со звездой вроде по совету анона прочитал на вики, теперь не могу снежинку вдуплить. Если у звезды просто инерр джоин во все поля, то со снежинкой неясно, чем она отличается?
>Организация основной таблички типом «звезда», чтобы потом джойнить справочники только на нее?
Это.
Ну со звездой вроде по совету анона прочитал на вики, теперь не могу снежинку вдуплить. Если у звезды просто инерр джоин во все поля, то со снежинкой неясно, чем она отличается?
>>27213
Мне, как знающему sql на пятерку, но так и не осилившему front, например, кажется, что нет.
Мне, как знающему sql на пятерку, но так и не осилившему front, например, кажется, что нет.
Посоветуйте как вкатиться, мне он нужен для бэкенда, какую-нибудь книжку или видео курс, который поможет разработчику быстро освоить нужный минимум по работе с базами данных
>>27399
О найс, спасибо
О найс, спасибо
>>11264
Привет. Не писал, только использовал logminer. Гуглится redo log dissecting, но статья старая.
Привет. Не писал, только использовал logminer. Гуглится redo log dissecting, но статья старая.
>>29641
Угу, нашел какую-то дедовскую статью для 9 версии, дай бог здоровья людям.
Заголовки файла и магические числа вроде совпали для 12. Правда под винду все. Сами данные тоже локализовал, и описание длинны полей. С текстом просто, а вот числа довольно интересно хрянятся, суммы чисел умноженых на десятки в квадрате. Не могу пока с заголовком записи разобраться, длину ее найти, целиком. Все руки не доходят
Угу, нашел какую-то дедовскую статью для 9 версии, дай бог здоровья людям.
Заголовки файла и магические числа вроде совпали для 12. Правда под винду все. Сами данные тоже локализовал, и описание длинны полей. С текстом просто, а вот числа довольно интересно хрянятся, суммы чисел умноженых на десятки в квадрате. Не могу пока с заголовком записи разобраться, длину ее найти, целиком. Все руки не доходят
55 Кб, 627x393Есть БД, и есть задача Вывести список всех пользователей, у которых за год с момента их регистрации (Users.RegistrationDate) было совершено более 30 транзакций в валюте USD (WalletSections.Currency = 1).
Как правильно сделать выборку за период по времени с Users.RegistrationDate по (Users.RegistrationDate + 1 год)?
С остальными параметрами проще, но вот к периоду даже не знаю, как подступиться..
Как правильно сделать выборку за период по времени с Users.RegistrationDate по (Users.RegistrationDate + 1 год)?
С остальными параметрами проще, но вот к периоду даже не знаю, как подступиться..
>>29690
Разобрался
Select
U.userid, Count (t.transactionid)
From users u, wallets w, walletsections ws, transactions t
Where
u.userid=w.userid and
w.walletid=ws.walletid and
ws.walletsectionid=t.walletsectionid and
to_date(t.creationdate,'dd.mm.yyyy') between to_date(u.registrationdate,'dd.mm.yyyy') and add_month(to_date(u.registrationdate,'dd.mm.yyyy'),12)-1 and
ws.currency='USD'
group by u.userid
having count(t.transactionid)>30
Разобрался
Select
U.userid, Count (t.transactionid)
From users u, wallets w, walletsections ws, transactions t
Where
u.userid=w.userid and
w.walletid=ws.walletid and
ws.walletsectionid=t.walletsectionid and
to_date(t.creationdate,'dd.mm.yyyy') between to_date(u.registrationdate,'dd.mm.yyyy') and add_month(to_date(u.registrationdate,'dd.mm.yyyy'),12)-1 and
ws.currency='USD'
group by u.userid
having count(t.transactionid)>30
>>30022
Спасибо, пупсик
Спасибо, пупсик
55 Кб, 627x393Господа, как вот к такому запросу:
SELECT Employee.Age, Employee.Name
FROM Employee
INNER JOIN ProductEmployee ON Employee.ID = ProductEmployee.ID
INNER JOIN Product ON ProductEmployee.ID = Product.ID
WHERE Employee.Age > 50
GROUP BY Employee.ID
HAVING (COUNT(Product.ID) >= 10);
добавить вывод ещё одного значения после сортировки, самого последнего по дате:
(SELECT Product.Name ORDER BY ProductEmployee.Date DESC LIMIT 1)
SELECT Employee.Age, Employee.Name
FROM Employee
INNER JOIN ProductEmployee ON Employee.ID = ProductEmployee.ID
INNER JOIN Product ON ProductEmployee.ID = Product.ID
WHERE Employee.Age > 50
GROUP BY Employee.ID
HAVING (COUNT(Product.ID) >= 10);
добавить вывод ещё одного значения после сортировки, самого последнего по дате:
(SELECT Product.Name ORDER BY ProductEmployee.Date DESC LIMIT 1)
38 Кб, 628x440>>30355
правильная схема
правильная схема
146 Кб, 725x1340Где почитать внятных материалов по этим вашим sql'ям, чтобы подготовиться к собесу? Всякие btree, составные индексы, уровни изоляции транзакций и всё такое я знаю (или думаю, что знаю), но вангую, что меня спросят какую-нибудь хуйню вида "а как вакуум в постгресе работает и чем он отличается от аналогичных процессов в innodb" (реальный вопрос, спросили как-то раз) и я в лужу сяду.
>>30480
А куда и накого про вакуум спрашивали? Одно дело вопрос, что такое и для чего вакуум, а другое как работает. Да и тут могут бвть разные уровни детализации ответа. Для одного уровня достаточно доки, если подробнее, надо искать специализированные статьи или в исходники лезть. Боюсь по вопросам такого типа одного источника не найти, все нужно гуглить отдельно и иногда по исходникам
А куда и накого про вакуум спрашивали? Одно дело вопрос, что такое и для чего вакуум, а другое как работает. Да и тут могут бвть разные уровни детализации ответа. Для одного уровня достаточно доки, если подробнее, надо искать специализированные статьи или в исходники лезть. Боюсь по вопросам такого типа одного источника не найти, все нужно гуглить отдельно и иногда по исходникам
>>30494
Да я просто разработчик и мне вообще непонятно, зачем мне знать про вакуум, если я не собеседуюсь на администратора баз данных. Я должен знать интерфейс базы данных и особенности работы с ней, чтобы эффективно её использовать, не более.
Да я просто разработчик и мне вообще непонятно, зачем мне знать про вакуум, если я не собеседуюсь на администратора баз данных. Я должен знать интерфейс базы данных и особенности работы с ней, чтобы эффективно её использовать, не более.
>>30506
Ну если хайлод какой, то может быть полезно, хотя сам механизм работы все-таки непонятно для чего знать, в данном случае.
Ну если хайлод какой, то может быть полезно, хотя сам механизм работы все-таки непонятно для чего знать, в данном случае.
>>30558
Ну это понятно. А какие популярные вопросы вообще есть про бд? У меня личный топ часто задаваемых вопросов (сеньор левел) - это что такое индекс, как он работает, как работает при сортировке, уровни изоляции и напишите какую-нибудь хуйню с тремя джоинами.
А самым сложным заданием было написать запрос, который из колонки, в которой хранятся числа (1,2,3,5,6,7,10) выведет промежутки ([1,3],[5,5],[6,7],[10,10]).
Ну это понятно. А какие популярные вопросы вообще есть про бд? У меня личный топ часто задаваемых вопросов (сеньор левел) - это что такое индекс, как он работает, как работает при сортировке, уровни изоляции и напишите какую-нибудь хуйню с тремя джоинами.
А самым сложным заданием было написать запрос, который из колонки, в которой хранятся числа (1,2,3,5,6,7,10) выведет промежутки ([1,3],[5,5],[6,7],[10,10]).
Появилась необходимость написать синтаксический анализатор для MS SQL запросов. Найти описание грамматики в каком-нибудь вменяемом виде не смог (желательно БНФ). Имеется ли таковое в открытом доступе?
37 Кб, 500x442Аноны, посоветуйте плз годных бесплатных онлайн курсов по SQL (или книг). Учебник на sql-ex периодически падает на полчаса - час, чет херово это, когда почитать хочешь.
Знаю на W3C есть, но он вроде совсем для нубасов - так получить общее представление, хотелось бы что-нибудь посолиднее.
Знаю на W3C есть, но он вроде совсем для нубасов - так получить общее представление, хотелось бы что-нибудь посолиднее.
Ywgsgfs
Предположим есть таблица "Сотрудники". И есть таблица "Отделы". Отделы-сотрудники - 1 ко многим. Куда мне запихнуть поле "Начальник отдела", где указывается айди сотрудника, ведь в этом случае появляется дополнительное отношение 1 к 1, что тупо?
>>31019
Не поле, а тэг.
Не поле, а тэг.
>>31012
По сути я так и думал делать табличку "Должности" и там одна из строк типа "Начальник отдела", но, в общем, спасибо. Хотя и нагуглил вариант, про который выше написал, но он мне не нравится.
По сути я так и думал делать табличку "Должности" и там одна из строк типа "Начальник отдела", но, в общем, спасибо. Хотя и нагуглил вариант, про который выше написал, но он мне не нравится.
>>30561
Ну еще про типы джоинов, nested, merge, hash. Как работают, когда лучше использовать. Типы индесков.
Если по ораклу: хинты, redo/undo, direct path операции, методы доступа к данным (типы доступов по индексу, сканирования), партиционирование, тэйблспэсы, устройство памяти, pga, sga, локи.
Оптимизация в зависимости от типа базы, oltp или olap.
Postgres - тот же вакуум, но это скорее про то, каким образом acid поддерживается в базе. Как можно влиять на план выполнения без хинтов. По конкретно по пг больше вспомнить не могу.
По mpp, как работают бродкасты редистрибьюции. Какой ключ дистрибьюции лучше выбрать.
По sql не помню, давно уже не спрашивали. Доводилось строить план выполнения по продиктованному запросу.
Это конечно далеко не полный список
Ну еще про типы джоинов, nested, merge, hash. Как работают, когда лучше использовать. Типы индесков.
Если по ораклу: хинты, redo/undo, direct path операции, методы доступа к данным (типы доступов по индексу, сканирования), партиционирование, тэйблспэсы, устройство памяти, pga, sga, локи.
Оптимизация в зависимости от типа базы, oltp или olap.
Postgres - тот же вакуум, но это скорее про то, каким образом acid поддерживается в базе. Как можно влиять на план выполнения без хинтов. По конкретно по пг больше вспомнить не могу.
По mpp, как работают бродкасты редистрибьюции. Какой ключ дистрибьюции лучше выбрать.
По sql не помню, давно уже не спрашивали. Доводилось строить план выполнения по продиктованному запросу.
Это конечно далеко не полный список
>>31257
Он явно в курсе происходящего в движках бд, двачую этого ораклиста.
Он явно в курсе происходящего в движках бд, двачую этого ораклиста.
>>31040
На уровне структуры у тебя получится так, что может быть много начальников. Чтобы этого избежать, надо в отделах сделать айдишник руководителя.
На уровне структуры у тебя получится так, что может быть много начальников. Чтобы этого избежать, надо в отделах сделать айдишник руководителя.
>>31411
Пф, а ещё айдишник заместителя руководителя, заместителя заместителя, бухгалтера и всех прочих, кто может быть один, ага. Проще уж constraint'ом задать уникальность для тэга.
Пф, а ещё айдишник заместителя руководителя, заместителя заместителя, бухгалтера и всех прочих, кто может быть один, ага. Проще уж constraint'ом задать уникальность для тэга.
>>31425
Ну ты спрашивал про руководителя.
Начальник всегда один у отдела.
А бухгалтеров и замов может быть сколько угодно.
Ну ты спрашивал про руководителя.
Начальник всегда один у отдела.
А бухгалтеров и замов может быть сколько угодно.
Аноны, почему плейсхолдеры быстрее сабселекта?
В случае с плейсхолдерами мой запрос что то типо
select form posts where parent in ?, ? и так далее..
Под ? идет индекс треда, их всего 250
В случае с сабселектом там что то типо
select from posts, (select * from threads where board_id=? order by lasthit desc limit ?) as threads where posts.parent=threads.id || 2, 250
Итого: 350 всего/250 живых тредов , 700к всего/500к живых постов:
Плейсхолдеры: 4 секунды,
Сабселект: 14 секунд
Где я обосрался? Сами плейсхолдеры получаю тем, что написанно в сабселекте через другой запрос
В случае с плейсхолдерами мой запрос что то типо
select form posts where parent in ?, ? и так далее..
Под ? идет индекс треда, их всего 250
В случае с сабселектом там что то типо
select from posts, (select * from threads where board_id=? order by lasthit desc limit ?) as threads where posts.parent=threads.id || 2, 250
Итого: 350 всего/250 живых тредов , 700к всего/500к живых постов:
Плейсхолдеры: 4 секунды,
Сабселект: 14 секунд
Где я обосрался? Сами плейсхолдеры получаю тем, что написанно в сабселекте через другой запрос
>>33480
Открой план запроса же.
Второй запрос у тебя с САБСЕЛЕКТОМ написан просто ужасно, если что. Когда такое вижу, аж плохо становится.
>почему быстрее?
Открой план запроса же.
Второй запрос у тебя с САБСЕЛЕКТОМ написан просто ужасно, если что. Когда такое вижу, аж плохо становится.
Аноны, щас зарабатываю тем, что просто пищу всякие хранимки для отчётов в MS SQL, но есть желание развиваться, а конкретно - развиваться в Биг Дата и Хай Лоад, хочу изучать Hadoop, Spark, вот это всё. Во многих вакансиях, ко всему прочему, просят знания ETL, OLAP, DWH и прочей аналитики на SQL. Собственно, тут возникает вопрос, на чём мне лучше всего это изучать? Остаться на MS SQL или начать изучать Oracle? Какая СУБД более востребована на нашем рынке в Биг Дате и аналитике? дс2
>>33532
На MS SQL точно оставаться не надо.
Еще определись с направлением. HighLoad это обычно очень большое количество мелких операций, которые требуется выполнять очень быстро.
Хранилища - это обычно грандиозная пиковая нагрузка, где оперируют большими объемами данных за раз. И там часто возникает вопрос отработает-не отработает и за какой период времени.
Сотвественно базы создаются и настраиваются несколько по разному для хайлода и хранилищ, и способы оптимизации различаются.
Bigdata и прочие hadoop-ы это идет обычно в связке с хранилищами(dwh) . Технологии отличаются от реляционок, хоть и чем-то похожи
Сейчас стараются строить хранилища по следующему принципу: на основе hadoop технологий как первичного слоя для хранения и превращения сырых данных в более менее подготовленные для загрузки в реляционки. В качестве реляционок стараются использовать MPP системы. GreenPlum хороший пример, есть и другие решения, Teradata например, Vertica помоему тоже MPP.
Про хайлоду не могу стазать по технологиям точно, там скорее всего помимо реляционок идет много работы с inmemory базами, где база по сути это гигантский кэш в оперативке, большая хэш-таблица. Но какой-нибудь oracle тоже не помешает, у них довольно хорошая дока, и можно подтянуть общие принципы и понимание работы реляционной бд изучая его. Postgres - у него открытые исходники и тоже довольно подробная документация.
По хранилищам это изучение MPP баз. Я бы выбрал GreenPlum - открытые исходники, подробная дока, сдедан на основе postgres. Ну и отдельным стеком решения на базе Hadoop. Там целый зоопарк, но довольно часто можно встретить связку hadoop - yarn - spark, ну и что нибудь из эмуляции БД для hadoop по типу hive. Понимание oracle или postgres впринципе и тут также очень пригодится
На MS SQL точно оставаться не надо.
Еще определись с направлением. HighLoad это обычно очень большое количество мелких операций, которые требуется выполнять очень быстро.
Хранилища - это обычно грандиозная пиковая нагрузка, где оперируют большими объемами данных за раз. И там часто возникает вопрос отработает-не отработает и за какой период времени.
Сотвественно базы создаются и настраиваются несколько по разному для хайлода и хранилищ, и способы оптимизации различаются.
Bigdata и прочие hadoop-ы это идет обычно в связке с хранилищами(dwh) . Технологии отличаются от реляционок, хоть и чем-то похожи
Сейчас стараются строить хранилища по следующему принципу: на основе hadoop технологий как первичного слоя для хранения и превращения сырых данных в более менее подготовленные для загрузки в реляционки. В качестве реляционок стараются использовать MPP системы. GreenPlum хороший пример, есть и другие решения, Teradata например, Vertica помоему тоже MPP.
Про хайлоду не могу стазать по технологиям точно, там скорее всего помимо реляционок идет много работы с inmemory базами, где база по сути это гигантский кэш в оперативке, большая хэш-таблица. Но какой-нибудь oracle тоже не помешает, у них довольно хорошая дока, и можно подтянуть общие принципы и понимание работы реляционной бд изучая его. Postgres - у него открытые исходники и тоже довольно подробная документация.
По хранилищам это изучение MPP баз. Я бы выбрал GreenPlum - открытые исходники, подробная дока, сдедан на основе postgres. Ну и отдельным стеком решения на базе Hadoop. Там целый зоопарк, но довольно часто можно встретить связку hadoop - yarn - spark, ну и что нибудь из эмуляции БД для hadoop по типу hive. Понимание oracle или postgres впринципе и тут также очень пригодится
>>33813
Спасибо за ответ, Анон
Почему на MS SQL лучше не оставаться? Только из за привязки по стеку Майкрософта? Вообще, у MS SQL вроде как есть SSAS, которые тоже позволяет работать с хранилищами, разве нет? Да и на HH почти во всех вакансиях, в которых упоминается DWH, требуют MS SQL, а тот же GreenPlum упоминается только в пяти вакансиях. Так в чём его преимущество?
С постгрессом знаком не много, а oracke даже в глаза не видел. Думаешь, нормально продолжить погружаться в postgres вместо того, что бы начинать изучать oracle с нуля?
В общем, благодаря тебе у меня примерно сформировался стэк в голове, который мне нужно изучить:
1) hadoop - yarn - spark
2) postgres + GreenPlum
После этого можно идти стучаться на галеры или нужно что то ещё?
Спасибо за ответ, Анон
>На MS SQL точно оставаться не надо.
>GreenPlum хороший пример, есть и другие решения, Teradata например, Vertica помоему тоже MPP.
Почему на MS SQL лучше не оставаться? Только из за привязки по стеку Майкрософта? Вообще, у MS SQL вроде как есть SSAS, которые тоже позволяет работать с хранилищами, разве нет? Да и на HH почти во всех вакансиях, в которых упоминается DWH, требуют MS SQL, а тот же GreenPlum упоминается только в пяти вакансиях. Так в чём его преимущество?
> Понимание oracle или postgres в принципе и тут также очень пригодится
С постгрессом знаком не много, а oracke даже в глаза не видел. Думаешь, нормально продолжить погружаться в postgres вместо того, что бы начинать изучать oracle с нуля?
В общем, благодаря тебе у меня примерно сформировался стэк в голове, который мне нужно изучить:
1) hadoop - yarn - spark
2) postgres + GreenPlum
После этого можно идти стучаться на галеры или нужно что то ещё?
>>33827
Мне кажется просто он пидор с опенсорсом головного мозга. Я конечно хз чотам щаз в тренде, но BI на посгрес, звучит как анекдот.
А так и у мелкомягких и у оракла есть свои решений, и интерпрайз весь на них.
Мне кажется просто он пидор с опенсорсом головного мозга. Я конечно хз чотам щаз в тренде, но BI на посгрес, звучит как анекдот.
А так и у мелкомягких и у оракла есть свои решений, и интерпрайз весь на них.
>>33827
На текущий момент не видел и не слышал, чтобы кто-то строил или планировал хранилища на MS, задчи миграции с него на другие решения, да видел. С оракла тоже стараются уходить там где это возможно. Желания такие по крайней мере часто слышал.
Достаточно, можно впринципе первое или второе изучить и начинать вкатываться, а остальную часть по ходу дела разбирать. Еще скриптовой язык не помешает, shell,python и работа с терминалом.
По поводу знания конкретной базы: тут суть не в самой технологии, а в базовых навыках и понимании. Тебе это сильно пригодится для решения многих задач, если будешь работать базами в принципе. Не сильно важно какая база, просто нужно хорошо знать, как она работает.
На текущий момент не видел и не слышал, чтобы кто-то строил или планировал хранилища на MS, задчи миграции с него на другие решения, да видел. С оракла тоже стараются уходить там где это возможно. Желания такие по крайней мере часто слышал.
Достаточно, можно впринципе первое или второе изучить и начинать вкатываться, а остальную часть по ходу дела разбирать. Еще скриптовой язык не помешает, shell,python и работа с терминалом.
По поводу знания конкретной базы: тут суть не в самой технологии, а в базовых навыках и понимании. Тебе это сильно пригодится для решения многих задач, если будешь работать базами в принципе. Не сильно важно какая база, просто нужно хорошо знать, как она работает.
>>33856
Ну на HH просто дохуя вакансий по MS, в том числе DWH. У GreenPlum всего 5. Может на западе его активно юзают, но, похоже, не у нас.
Python знаю, а насколько нужно уметь с терминалом работать? На Баше скрипты писать?
Кстати,а не знаешь какие-нибудь площадки, которые предоставляют огромные объёмы данных, на которых можно тренироваться?
>На текущий момент не видел и не слышал, чтобы кто-то строил или планировал хранилища на MS
Ну на HH просто дохуя вакансий по MS, в том числе DWH. У GreenPlum всего 5. Может на западе его активно юзают, но, похоже, не у нас.
>Достаточно, можно в принципе первое или второе изучить и начинать вкатываться, а остальную часть по ходу дела разбирать. Еще скриптовой язык не помешает, shell,python и работа с терминалом.
Python знаю, а насколько нужно уметь с терминалом работать? На Баше скрипты писать?
Кстати,а не знаешь какие-нибудь площадки, которые предоставляют огромные объёмы данных, на которых можно тренироваться?
>>33859
Не рвись ты так красноглазый. Анон полный набор для BI в вопросе перечислил как бе.
Не рвись ты так красноглазый. Анон полный набор для BI в вопросе перечислил как бе.
>>33532
Не поверишь, но лучше всего изучать сам SQL, тот же етл, по сути состоит из сплошных sql запросов чуть более чем полностью. Хранилка имеет свои нюансы конечно, но в целом это та же бд. В нагрузку можно учить mdx/dax. Вобще есть мнение что все уже вернулись от кубов к табличной модели.
Не поверишь, но лучше всего изучать сам SQL, тот же етл, по сути состоит из сплошных sql запросов чуть более чем полностью. Хранилка имеет свои нюансы конечно, но в целом это та же бд. В нагрузку можно учить mdx/dax. Вобще есть мнение что все уже вернулись от кубов к табличной модели.
>>02870 (OP)
Кароче, есть необходимость сделать метрики для предприятия.
У предприятия часть необходимых данных хранится в 1С.
Хранение, очевидно, файловое.
1Сника у предприятия нет. Только-только уволился и ищут что-то новое.
Может кто подсказать, кто с 1С работал. Если я приду и скажу новому исполнителю который только пришел - хуяч мне SQL-сервак - он меня пошлет? Какие варианты есть еще тогда работы с бд 1С?
Или только заказывать csv у 1Сника с обновлением раз в сутки?
Кароче, есть необходимость сделать метрики для предприятия.
У предприятия часть необходимых данных хранится в 1С.
Хранение, очевидно, файловое.
1Сника у предприятия нет. Только-только уволился и ищут что-то новое.
Может кто подсказать, кто с 1С работал. Если я приду и скажу новому исполнителю который только пришел - хуяч мне SQL-сервак - он меня пошлет? Какие варианты есть еще тогда работы с бд 1С?
Или только заказывать csv у 1Сника с обновлением раз в сутки?
>>33933
Нет не знаю, может аноны подскажут, по площадке с данными сам как-то искал и не нашел.
Скриптовой язык обычно требуется для датаинженеров, если в hadoop стек углубишься. Да глубокие знания не требуются, просто уметь.
Я думаю далеко не все вакансии по ms это dwh. Открыл первые три попавшиеся по dwh, ни слова про ms.
И сама по себе работа с базой, это не всегда работа с большими данными. Если хочешь прокачаться именно в этом направлении, ищи проекты с объемами баз от 50 терабайт примерно, где множество систем источников и приемников, множество процессов загрузи и выгрузки данных. Сотовые операторы, те же мэйлы и яндексы, авито, банки крупные, ресурсодобывающие организации.
Иначе попадешь в болото из 10 табличек, и 5 отчетов с сервером на локалке. Думаю вакансии по ms в большей степени как раз про это. Потратишь время зря.
Нет не знаю, может аноны подскажут, по площадке с данными сам как-то искал и не нашел.
Скриптовой язык обычно требуется для датаинженеров, если в hadoop стек углубишься. Да глубокие знания не требуются, просто уметь.
Я думаю далеко не все вакансии по ms это dwh. Открыл первые три попавшиеся по dwh, ни слова про ms.
И сама по себе работа с базой, это не всегда работа с большими данными. Если хочешь прокачаться именно в этом направлении, ищи проекты с объемами баз от 50 терабайт примерно, где множество систем источников и приемников, множество процессов загрузи и выгрузки данных. Сотовые операторы, те же мэйлы и яндексы, авито, банки крупные, ресурсодобывающие организации.
Иначе попадешь в болото из 10 табличек, и 5 отчетов с сервером на локалке. Думаю вакансии по ms в большей степени как раз про это. Потратишь время зря.
>>33982
Там в два клика 1с привязывается к базе данных. Так и говоришь, положи мне базу 1с в базу данных.
Там в два клика 1с привязывается к базе данных. Так и говоришь, положи мне базу 1с в базу данных.
>>34009
Как я понял сейчас у предприятия вообще никакой бд нет, только 1С. 1Сник сможет SQL-сервак на его выбор поставить? Мне не принципиально к чему запросы делать.
Или это вообще вне его компетенции?
Как я понял сейчас у предприятия вообще никакой бд нет, только 1С. 1Сник сможет SQL-сервак на его выбор поставить? Мне не принципиально к чему запросы делать.
Или это вообще вне его компетенции?
>>34009
Да но учти ставить и настраивать БД, это не работа 1сника, не исключено что он это умеет, но не обязан, так что может послать. Вобще серверами должен заниматься сисадмин. Он поднимает скуль, а 1сник просто указывет сервер-источник. Есть вариант на линуксе, которые бесплатны, но нужен человек который сможет настроить. Можно разово забашлять аутсорсерам чтоб сделали сервер, а потом 1сник пусть сам занимается.
Да но учти ставить и настраивать БД, это не работа 1сника, не исключено что он это умеет, но не обязан, так что может послать. Вобще серверами должен заниматься сисадмин. Он поднимает скуль, а 1сник просто указывет сервер-источник. Есть вариант на линуксе, которые бесплатны, но нужен человек который сможет настроить. Можно разово забашлять аутсорсерам чтоб сделали сервер, а потом 1сник пусть сам занимается.
Пиздец, еле как нашел ваш тред... Как работают транзакции? Касаемо mysql. Вот, например. Есть одно соединение с бд на сервере, которое обрабатывает запросы пользователей, они могут вставлять свои данные в бд. Но проблема в том, что они не могут вставлять одинаковые данные. Как разрулить эту ситуацию? Советуют использовать транзакции. Но в чем их суть? Вот, как это понимаю я:
Пользователь A хочет добавить 'хуй' и пользователь B тоже хочет добавить 'хуй'.
1 ситуация: они это делают в разное время. Перед вставкой в бд сначала происходит проверка на наличие вставляемых данных и если их нет, то выполняется вставка. Итог: пользователь A добавил 'хуй' в бд, пользователь B захотел добавить, не прошел проверку, был послан на хуй.
2 ситуация: оба пользователя делают это одновременно. Для каждого из них проверка выполняется успешно - 'хуй'я нет еще в бд, соответственно, они оба вставляют два 'хуй'я в бд, чего быть не должно. Окей, используем транзакцию. Вместо обычного
пишем
Транзакция должна заблокировать таблицу над которой выполняются операции? И отработает только одна из них? Или вторая зависнет, дождется завершения первой, после чего выполнит себя повторно, вставив 'хуй' дважды? Или как? Или что?
Пользователь A хочет добавить 'хуй' и пользователь B тоже хочет добавить 'хуй'.
1 ситуация: они это делают в разное время. Перед вставкой в бд сначала происходит проверка на наличие вставляемых данных и если их нет, то выполняется вставка. Итог: пользователь A добавил 'хуй' в бд, пользователь B захотел добавить, не прошел проверку, был послан на хуй.
2 ситуация: оба пользователя делают это одновременно. Для каждого из них проверка выполняется успешно - 'хуй'я нет еще в бд, соответственно, они оба вставляют два 'хуй'я в бд, чего быть не должно. Окей, используем транзакцию. Вместо обычного
>INSERT INTO...
пишем
>START TRANSACTION
>INSERT INTO....
>COMMIT
Транзакция должна заблокировать таблицу над которой выполняются операции? И отработает только одна из них? Или вторая зависнет, дождется завершения первой, после чего выполнит себя повторно, вставив 'хуй' дважды? Или как? Или что?
>>33985
Ну сейчас я как раз на MS SQL работаю, и там в одной БД больше 1000 таблиц, а такая БД на сервере ни одна, да и инстанс тоже не один. А для бдшек с 10 табличками, по моему, MySQL используют, и врятли таким компаниям вообще DWH нужен.
>Иначе попадешь в болото из 10 табличек, и 5 отчетов с сервером на локалке. Думаю вакансии по ms в большей степени как раз про это. Потратишь время зря.
Ну сейчас я как раз на MS SQL работаю, и там в одной БД больше 1000 таблиц, а такая БД на сервере ни одна, да и инстанс тоже не один. А для бдшек с 10 табличками, по моему, MySQL используют, и врятли таким компаниям вообще DWH нужен.
>>34061
Оба вставляют хуй, первый хуй вставляется с успехом, но второй уже не лезет. Соотвествено идет отмена первого хуя, оба пользователя ловят ошибку, не один хуй не вставлен. Образно говоря как логическое И, вставляются или оба хуя, или ни одного. Оба хуя должны быть в одной транзакции офк.
Оба вставляют хуй, первый хуй вставляется с успехом, но второй уже не лезет. Соотвествено идет отмена первого хуя, оба пользователя ловят ошибку, не один хуй не вставлен. Образно говоря как логическое И, вставляются или оба хуя, или ни одного. Оба хуя должны быть в одной транзакции офк.
>>34101
Ну и плюс пока хуй не вставлен, пользователь не получает сообщение о сукесе.
Ну и плюс пока хуй не вставлен, пользователь не получает сообщение о сукесе.
>>34101
Что значит в одной транзакции? Я что-то не понимаю. Т.е. транзакции не решают мою проблему? Мне надо как-то разрулить одновременные попытки вставки одинаковых данных.
Что значит в одной транзакции? Я что-то не понимаю. Т.е. транзакции не решают мою проблему? Мне надо как-то разрулить одновременные попытки вставки одинаковых данных.
>>34103
Перефразирую, транзакция обеспечивает выполнение запросов собранных в ней, т.е. если один из шагов рамках транзакции фейлится, отменяется вся транзакция.
Перефразирую, транзакция обеспечивает выполнение запросов собранных в ней, т.е. если один из шагов рамках транзакции фейлится, отменяется вся транзакция.
>>34109
Ну, про это я читал. А что будет, если каждый из пользователей создает транзакцию? И не просто создает, а они одновременно их создают?
Ну, про это я читал. А что будет, если каждый из пользователей создает транзакцию? И не просто создает, а они одновременно их создают?
>>34112
Если я правильно понял, как только пользователь запишет что-то, то второй запишет после. Это никак не решает мою проблему с одновременной вставкой, ибо проверка уже прошла для обоих и сказала, что данные можно вставлять.
Если я правильно понял, как только пользователь запишет что-то, то второй запишет после. Это никак не решает мою проблему с одновременной вставкой, ибо проверка уже прошла для обоих и сказала, что данные можно вставлять.
>>34115
А в чем проблеиа? Второй запрос ничего не запишет и вернет ошибку, как если бы он изначально не мог вставить, т.е. для пользователя разницы нет. Если у тебя списывается из таблице А и записывается в таблицу Б, то вот это и собирай в транзакцию.
А в чем проблеиа? Второй запрос ничего не запишет и вернет ошибку, как если бы он изначально не мог вставить, т.е. для пользователя разницы нет. Если у тебя списывается из таблице А и записывается в таблицу Б, то вот это и собирай в транзакцию.
53 Кб, 1506x784>>34116
Нет, мне нужно просто, чтобы данные не дублировались. Я в одном из тредов уже писал про это, но там мне не сильно помогли. Проблема на пике.
А with lock нужно в транзакциях использовать? Блять, я запутался...
Нет, мне нужно просто, чтобы данные не дублировались. Я в одном из тредов уже писал про это, но там мне не сильно помогли. Проблема на пике.
А with lock нужно в транзакциях использовать? Блять, я запутался...
>>34119
А вобще зависит от бд, гугли свю бд на lock/lock table
А вобще зависит от бд, гугли свю бд на lock/lock table
>>34119
Не надо пока этих томов только, плиз... Я сейчас хочу понять, в том ли я направлении вообще думаю. И я не уверен, что вы вообще поняли что я хочу. Это первое. Второе. У меня mysql, толку от этих конструкций, их может и не быть.
Я хочу понять: две транзакции, они как-то блокируют друг друга? Вот одновременно их отправили на исполнение.. В обеих только вставка однотипных данных. Но какая-то из них все равно будет принята на исполнение быстрее. Так вот та, что быстрее начнет выполняться, она запретит остальным транзакциям выполняться?
Не надо пока этих томов только, плиз... Я сейчас хочу понять, в том ли я направлении вообще думаю. И я не уверен, что вы вообще поняли что я хочу. Это первое. Второе. У меня mysql, толку от этих конструкций, их может и не быть.
Я хочу понять: две транзакции, они как-то блокируют друг друга? Вот одновременно их отправили на исполнение.. В обеих только вставка однотипных данных. Но какая-то из них все равно будет принята на исполнение быстрее. Так вот та, что быстрее начнет выполняться, она запретит остальным транзакциям выполняться?
>>34125
А когда она выполнится, что будет? Залоченные транзакции начнут постепенно выполняться? Или они уже ВСЕ?
А когда она выполнится, что будет? Залоченные транзакции начнут постепенно выполняться? Или они уже ВСЕ?
>>34118
Если иебе нужно, чтобы одинаковые данные не вставлялись, напиши запрос так, чтобы если хуй уже есть, то его вставлять не надо. В ms sql для этого есть merge.
Если merge нет, пиши insert если хуя нет, и update, если хуй есть.
И создай на табличку unique constraint на поле, в которое хочешь вставлять хуй, чтобы прям на уровне бд разруливать эти вопросы.
Если иебе нужно, чтобы одинаковые данные не вставлялись, напиши запрос так, чтобы если хуй уже есть, то его вставлять не надо. В ms sql для этого есть merge.
Если merge нет, пиши insert если хуя нет, и update, если хуй есть.
И создай на табличку unique constraint на поле, в которое хочешь вставлять хуй, чтобы прям на уровне бд разруливать эти вопросы.
>>34126
Конечно, они выполнятся.
Конечно, они выполнятся.
>>34127
Не получится, потому что хуй может быть и не уникальным по своей природе, но разным по длине.
хуй 25
хуй 14
хуй 6
- все это нормально, но
хуй 25
хуй 25
хуй 14
хуй 6
- не может быть. Поэтому unique запретит мне много хуев разной длины добавлять.
Не получится, потому что хуй может быть и не уникальным по своей природе, но разным по длине.
хуй 25
хуй 14
хуй 6
- все это нормально, но
хуй 25
хуй 25
хуй 14
хуй 6
- не может быть. Поэтому unique запретит мне много хуев разной длины добавлять.
>>34126
Нет, они посыпятся с ошибкой когда увидят что база залочена. В майскуль есть отдельная функция lock. Но как писал анон выше мне кажется в твоём случае нужно действавать иначе, например добавить If exist какой-нибудь, чтоб оно проверялось перед вставкой, и уже в зависимости от результата действовал.
Нет, они посыпятся с ошибкой когда увидят что база залочена. В майскуль есть отдельная функция lock. Но как писал анон выше мне кажется в твоём случае нужно действавать иначе, например добавить If exist какой-нибудь, чтоб оно проверялось перед вставкой, и уже в зависимости от результата действовал.
>>34130
Составной ключ?
Составной ключ?
>>34130
Забыл добавить: тут может быть еще и пизда со своей глубиной, по этому второй столбец тоже не может быть unique, ибо не получится записать
хуй 15
пизда 15
Забыл добавить: тут может быть еще и пизда со своей глубиной, по этому второй столбец тоже не может быть unique, ибо не получится записать
хуй 15
пизда 15
>>34130
Очевидно, задача на примере хуев и пезд - плохая задача.
Сформулируй понятнее, что тебе нужно, но уже сейчас видно, что транзакции - вовсе не то, что тебе нужно использовать для ее решения.
Ты можешь сделать уникальный индекс по нескольким полям, если что.
Очевидно, задача на примере хуев и пезд - плохая задача.
Сформулируй понятнее, что тебе нужно, но уже сейчас видно, что транзакции - вовсе не то, что тебе нужно использовать для ее решения.
Ты можешь сделать уникальный индекс по нескольким полям, если что.
>>34136
Два чаю этому, для начала определи какие атрибуты тебе нужны для определения уникольнной позиции. Может вобще стоит нормализовать и хуи с пездами растащить по разным таблицам
Два чаю этому, для начала определи какие атрибуты тебе нужны для определения уникольнной позиции. Может вобще стоит нормализовать и хуи с пездами растащить по разным таблицам
>>34136
А вдруг он пишет магазин для взрослых?
А вдруг он пишет магазин для взрослых?
>>34136
Окей, номер игровой сессии и сервер на котором она проходила. Может быть
gameId serverId
1 2
2 2
5 2
1 1
1 3
Мне лишь нужно, чтобы 2 юзера не сделали такую хуйню (на самом деле их сколько угодно может быть, дубликаты вообще не нужны)
gameId serverId
1 2
1 2
Окей, номер игровой сессии и сервер на котором она проходила. Может быть
gameId serverId
1 2
2 2
5 2
1 1
1 3
Мне лишь нужно, чтобы 2 юзера не сделали такую хуйню (на самом деле их сколько угодно может быть, дубликаты вообще не нужны)
gameId serverId
1 2
1 2
>>34139
Create unique nonclustered index IX_t_game_server on t_game_server (game_id, server_id)
Вот и все
Create unique nonclustered index IX_t_game_server on t_game_server (game_id, server_id)
Вот и все
>>34143
Не уверен, что констейнт можно ра 2 поля создать, пишу с айпада, проверять негде. А индекс точно можно.
Не уверен, что констейнт можно ра 2 поля создать, пишу с айпада, проверять негде. А индекс точно можно.
>>34146
Он даст тебе гарантию, что в твоей табличке не будет 2 строк с одинаковыми server_id и game_id
В твоем случае будет так:
Первый юзер заинсертит пару (1,1)
Второй юзер попытается заинсертить пару (1,1), и субд его пошлет, выдав ошибку (такая пара уже есть в табличке, хуй тебе)
>уникальный
Он даст тебе гарантию, что в твоей табличке не будет 2 строк с одинаковыми server_id и game_id
В твоем случае будет так:
Первый юзер заинсертит пару (1,1)
Второй юзер попытается заинсертить пару (1,1), и субд его пошлет, выдав ошибку (такая пара уже есть в табличке, хуй тебе)
>>34148
Хм, не знал что индексы и так работают, думал все это история для ускорения запросов. Я не тот анон с хуями, но за инфу спасибо.
Хм, не знал что индексы и так работают, думал все это история для ускорения запросов. Я не тот анон с хуями, но за инфу спасибо.
>>34149
Ты можешь сделать primary key по этим 2 колонкам, но это не рекомендуется, потомучто ссылаться на такую таблицу будет заебно.
Так что первичный ключ лучше юзать на автоинкрементную колонку.
В mysql сработает.
Сильно ли ударит по размеру бд?
Нет, не сильно. Но имей в виду, что индексы имеют свойство фрагментироваться, так что их периодически надо реорганизовывать или перестраивать.
Ты можешь сделать primary key по этим 2 колонкам, но это не рекомендуется, потомучто ссылаться на такую таблицу будет заебно.
Так что первичный ключ лучше юзать на автоинкрементную колонку.
В mysql сработает.
Сильно ли ударит по размеру бд?
Нет, не сильно. Но имей в виду, что индексы имеют свойство фрагментироваться, так что их периодически надо реорганизовывать или перестраивать.
>>34076
Ну я поэтому и написал, "в большенстве случаев".
Предполагаю, что проекту около 10 лет или более. В общем выбор не типичный.
Ну я поэтому и написал, "в большенстве случаев".
Предполагаю, что проекту около 10 лет или более. В общем выбор не типичный.
>>33827
бля, где пять то?
В ДС на hh по greenplum сейчас 65 вакансий. И вакансия greenplum уже подразумевает DWH, потому что он больше нигде не используется.
Преимущество в том, что greenplum это именно BIGDATA. А хранилища на MSSQL это мелкие дрочь хранилища мидл сайз бизнесов. Или он просто упоминается в вакансиях, потому что много баз источников на MS SQL. Или иногда пишут что нужны знания реляционных баз и перечисляют просто базы распространенные.
Если хочешь вкатываться в DWH и Hadoopы, можешь просто ходить на собеседования. Просто пишешь знаю основы DWH/Hadoop, хочу вкатиться. Знаю хорошо реляционку. В болшинстве мест спрашивают только реляционку и если она ок, то берут и на месте прокачивают. Ну если ты конечно не на синьора претендуешь.
Чем сидеть год абстрактно читать книжки, можно устроиться гораздо раньше и на месте выучить гораздо больше вместе с практикой.
>Да и на HH почти во всех вакансиях, в которых упоминается DWH, требуют MS SQL, а тот же GreenPlum упоминается только в пяти вакансиях. Так в чём его преимущество?
>
бля, где пять то?
В ДС на hh по greenplum сейчас 65 вакансий. И вакансия greenplum уже подразумевает DWH, потому что он больше нигде не используется.
Преимущество в том, что greenplum это именно BIGDATA. А хранилища на MSSQL это мелкие дрочь хранилища мидл сайз бизнесов. Или он просто упоминается в вакансиях, потому что много баз источников на MS SQL. Или иногда пишут что нужны знания реляционных баз и перечисляют просто базы распространенные.
Если хочешь вкатываться в DWH и Hadoopы, можешь просто ходить на собеседования. Просто пишешь знаю основы DWH/Hadoop, хочу вкатиться. Знаю хорошо реляционку. В болшинстве мест спрашивают только реляционку и если она ок, то берут и на месте прокачивают. Ну если ты конечно не на синьора претендуешь.
Чем сидеть год абстрактно читать книжки, можно устроиться гораздо раньше и на месте выучить гораздо больше вместе с практикой.
>>34142
Не знаю, что-то я для mysql внятного и понятного не смог найти. Нашел только про составные ключи и написал
В принципе, работает, но есть проблема. Когда происходит попытка повторной записи, бд ее не пропускает, но для этой таблицы выполняет фиктивное увеличение первичного ключа, создавая "дыры" в порядке записей.
Затем я попробовал с помощью транзакций сделать тоже самое
Этой проблемы уже нет, но я не уверен что постоянно блокировать таблицу в моем случае правильно. Поэтому как можно решить проблему первого способа? Или же лучше транзакции оставить? Вообще, я в них могу засунуть сотни запросов, которые зависят друг от друга, что будет гарантировать целостность бд.
Не знаю, что-то я для mysql внятного и понятного не смог найти. Нашел только про составные ключи и написал
>create unique index uniq_ind on test (gameId, serverId);
В принципе, работает, но есть проблема. Когда происходит попытка повторной записи, бд ее не пропускает, но для этой таблицы выполняет фиктивное увеличение первичного ключа, создавая "дыры" в порядке записей.
Затем я попробовал с помощью транзакций сделать тоже самое
>INSERT INTO test (gameId, serverId)
>SELECT '${gameId}', '${serverId}'
>WHERE NOT EXISTS
> (SELECT id FROM test WHERE gameId='${gameId}' AND serverId='${serverId}')`;
Этой проблемы уже нет, но я не уверен что постоянно блокировать таблицу в моем случае правильно. Поэтому как можно решить проблему первого способа? Или же лучше транзакции оставить? Вообще, я в них могу засунуть сотни запросов, которые зависят друг от друга, что будет гарантировать целостность бд.
>>34398
типа последний инкрементальный id был 3, а следующий при инсерте будет не 4, а 5?
Не видно, что ты управляешь в запросе изоляцией транзакий - это во-первых
Во-вторых, я вообще не понимаю, что ты собираешься делать при помощи транзакций. Вот тебе простой пример того, как у тебя все сломается:
1. Инсертишь ты такой строку в базе, блокируя табличку.
2. И тут у тебя отваливается соединение с сетью. А транзакцию ты не закоммитил.
3. Все остальные сессии, заблокированные первой, будут висеть, пока подвисшая транзакция не будет закоммичена, то есть венчо.
>фиктивное увеличение ключа
типа последний инкрементальный id был 3, а следующий при инсерте будет не 4, а 5?
>затем я с помощью транзакций
Не видно, что ты управляешь в запросе изоляцией транзакий - это во-первых
Во-вторых, я вообще не понимаю, что ты собираешься делать при помощи транзакций. Вот тебе простой пример того, как у тебя все сломается:
1. Инсертишь ты такой строку в базе, блокируя табличку.
2. И тут у тебя отваливается соединение с сетью. А транзакцию ты не закоммитил.
3. Все остальные сессии, заблокированные первой, будут висеть, пока подвисшая транзакция не будет закоммичена, то есть венчо.
>>34471
Да
Насчет транзакций, я не знаю что такое "изоляция транзакций". А без транзакций тоже мало что приятного. Вот у меня есть такая ситуация:
Пользователь хочет записать всю информацию для одной игровой сессии, если этой игровой сессии нет в БД, то он вставит эту строчку (gameId, serverId), а после чего начнет заполнять 5 таблиц, которые содержат в себе необходимую инфу для этой сессии. И этих запросов с заполнением может быть несколько сотен. И вот тут проблема, если транзакций нет. На какой-то момент времени пользователь проверил, что (gameId, serverId) нет, он начал выполнять 10 запросов со вставкой, потмо еще 10, потом 20, а ему нужно еще где-то 100 запросов выполнить, и тут хуяк, сеть пропадает, все нахуй падает, 100 запросов не выполнились. Теперь у нас в БД "поврежденная" игровая сессия с частью информацией. А перезаписать ее повторно не получится, ибо связка (gameId, serverId) была записана и Бд считает, что для нее вся информация записана.
Это же как-то должно решаться?
>а следующий при инсерте будет не 4, а 5?
Да
Насчет транзакций, я не знаю что такое "изоляция транзакций". А без транзакций тоже мало что приятного. Вот у меня есть такая ситуация:
Пользователь хочет записать всю информацию для одной игровой сессии, если этой игровой сессии нет в БД, то он вставит эту строчку (gameId, serverId), а после чего начнет заполнять 5 таблиц, которые содержат в себе необходимую инфу для этой сессии. И этих запросов с заполнением может быть несколько сотен. И вот тут проблема, если транзакций нет. На какой-то момент времени пользователь проверил, что (gameId, serverId) нет, он начал выполнять 10 запросов со вставкой, потмо еще 10, потом 20, а ему нужно еще где-то 100 запросов выполнить, и тут хуяк, сеть пропадает, все нахуй падает, 100 запросов не выполнились. Теперь у нас в БД "поврежденная" игровая сессия с частью информацией. А перезаписать ее повторно не получится, ибо связка (gameId, serverId) была записана и Бд считает, что для нее вся информация записана.
>Все остальные сессии, заблокированные первой, будут висеть, пока подвисшая транзакция не будет закоммичена, то есть венчо.
Это же как-то должно решаться?
>>34398
Вроде это решается через констейнт по сути то же самое что и индекс, но проверяет перед вставкой, во стальном работает так же.
Вроде это решается через констейнт по сути то же самое что и индекс, но проверяет перед вставкой, во стальном работает так же.
>>34562
Т.е. лучше делать с транзакциями без того составного ключа, но с проверкой на уже записанные данные + настраивать время блокировки, чтобы не было вечно висящих транзакций?
Т.е. лучше делать с транзакциями без того составного ключа, но с проверкой на уже записанные данные + настраивать время блокировки, чтобы не было вечно висящих транзакций?
>>34573
Вот тебе решение, индекс на 2 поля оставь, по нему поиск будет работать.
И используй свой запрос для вставки с «where not exists».
Все.
Вот тебе решение, индекс на 2 поля оставь, по нему поиск будет работать.
И используй свой запрос для вставки с «where not exists».
Все.
>>34647
Мне нужно, чтобы данные все гарантированно записывались. Т.е. либо все, либо ничего. Чтобы в случае с всевозможными сбоями в БД не было говна.
Мне нужно, чтобы данные все гарантированно записывались. Т.е. либо все, либо ничего. Чтобы в случае с всевозможными сбоями в БД не было говна.
>>34553
>>34652
Да, это решается транзакциями, ты прав, не обратил внимания.
Все твои запросы должны быть в одной транзакции в таком случае:
START TRANSACTION
.... куча запросов
COMMIT
Но не забудь, что в таком случае ты должен разообраться с тем, что такое Rollback и как отлавливать ошибки.
Вот тут написано
https://stackoverflow.com/questions/30973002/try-catch-in-mysql-for-transaction
>>34652
Да, это решается транзакциями, ты прав, не обратил внимания.
Все твои запросы должны быть в одной транзакции в таком случае:
START TRANSACTION
.... куча запросов
COMMIT
Но не забудь, что в таком случае ты должен разообраться с тем, что такое Rollback и как отлавливать ошибки.
Вот тут написано
https://stackoverflow.com/questions/30973002/try-catch-in-mysql-for-transaction
>>34667
А rollback для чего, если при возникновении ошибки транзакция и так не выполнит commit? И все же, как тут писали:
С этим как бороться? Вот так?
Или лучше как-то иначе? Я бегло прочитал про какие-то ACID транзакции, которые выступают промежуточными, как я понял, между пользовательскими транзакциями, что дает возможность БД отлавливать зависшие транзакции и самой их разруливать как-то. Но это жрет дохуя ресурсов сервера, места на носителе информации и оперативной памяти. Короче, у меня есть чувство, что я лезу куда-то не туда и сам создаю себе проблемы.
А rollback для чего, если при возникновении ошибки транзакция и так не выполнит commit? И все же, как тут писали:
>Вот тебе простой пример того, как у тебя все сломается:
>1. Инсертишь ты такой строку в базе, блокируя табличку.
>2. И тут у тебя отваливается соединение с сетью. А транзакцию ты не закоммитил.
>3. Все остальные сессии, заблокированные первой, будут висеть, пока подвисшая транзакция не будет закоммичена, то есть венчо.
С этим как бороться? Вот так?
>У транзакций можно настроить время блокировки
Или лучше как-то иначе? Я бегло прочитал про какие-то ACID транзакции, которые выступают промежуточными, как я понял, между пользовательскими транзакциями, что дает возможность БД отлавливать зависшие транзакции и самой их разруливать как-то. Но это жрет дохуя ресурсов сервера, места на носителе информации и оперативной памяти. Короче, у меня есть чувство, что я лезу куда-то не туда и сам создаю себе проблемы.
>>34700
rollback и нужен для того, чтобы завершить транзакцию и все следующие, заблокированные ей, могли выполняться.
Бля, просто прочитай про транзакции.
rollback и нужен для того, чтобы завершить транзакцию и все следующие, заблокированные ей, могли выполняться.
Бля, просто прочитай про транзакции.
>>34721
Я читал и там было написано, что rollback нужен всего навсего для отката изменений. Поэтому я не очень понимаю, как он связан с зависшей транзакцией после сбоя работы бд.
Я читал и там было написано, что rollback нужен всего навсего для отката изменений. Поэтому я не очень понимаю, как он связан с зависшей транзакцией после сбоя работы бд.
>>34189
В дс2
Зато если искать по запросу DWH, то почти в каждой вакансии пишут о разработки хранилищ на MS SQL
>бля, где пять то?
В дс2
Зато если искать по запросу DWH, то почти в каждой вакансии пишут о разработки хранилищ на MS SQL
>>34765
Да такой же срач: грин пульм или мс скл, блжад, да похуй, вообще.
Просто грин пульм бесплатный, вот и нравится красноглазым.
По факту, абсолютно неважно, что ты там юзаешь, главное - принципы построения хранилищ понимать.
А реализация - сколько не ходил по собесам, всем похуй на опыт использования какой-то конкретной программы, если не умеешь, научат.
Да такой же срач: грин пульм или мс скл, блжад, да похуй, вообще.
Просто грин пульм бесплатный, вот и нравится красноглазым.
По факту, абсолютно неважно, что ты там юзаешь, главное - принципы построения хранилищ понимать.
А реализация - сколько не ходил по собесам, всем похуй на опыт использования какой-то конкретной программы, если не умеешь, научат.
>>34765
а ну тут ты попал в просак. На хоронища смысл идти только в большие конторы, там может быть 300к/сек.
А все большие конторы базируются в МСК, я имею ввиду энтерпрайз. В Питере есть разве что газпром-нефть, газпром(?), а дальше хз.
Тебя могут взять в сбер в Питере, но само хранилище в мск и ты будешь как бэ на вторых ролях всегда.
это дрочь конторы, в которых мало денег
>В дс2
а ну тут ты попал в просак. На хоронища смысл идти только в большие конторы, там может быть 300к/сек.
А все большие конторы базируются в МСК, я имею ввиду энтерпрайз. В Питере есть разве что газпром-нефть, газпром(?), а дальше хз.
Тебя могут взять в сбер в Питере, но само хранилище в мск и ты будешь как бэ на вторых ролях всегда.
>Зато если искать по запросу DWH, то почти в каждой вакансии пишут о разработки хранилищ на MS SQL
это дрочь конторы, в которых мало денег
>>34842
лол, ты там ему уже карьеру построил, сразу на ведущего разработчика с 300к\наносек, все сидят и ждут, только его не хватает.
лол, ты там ему уже карьеру построил, сразу на ведущего разработчика с 300к\наносек, все сидят и ждут, только его не хватает.
>>35145
норм, но надо обычно знать еще кучу попенсорс говна, которое вокруг
норм, но надо обычно знать еще кучу попенсорс говна, которое вокруг
>>35090
Да, ждут, толковых спецов в этом направлении не так много, а тех кто готов еще и все трудности кровавого энтерпрайза героически преодолевать, так и подавно.
Да, ждут, толковых спецов в этом направлении не так много, а тех кто готов еще и все трудности кровавого энтерпрайза героически преодолевать, так и подавно.
>>35247
Ну, я читаю Алан_Бьюли-Изучаем_SQL-Символ-Плюс(2007).pdf Вроде, норм. Еще Бейли Л. - Изучаем SQL (Бестселлеры O'Reilly) - 2012.pdf неплохая. Если совсем даун, то лучше с нее начать, имхо. Там даже картиночки есть.
Ну, я читаю Алан_Бьюли-Изучаем_SQL-Символ-Плюс(2007).pdf Вроде, норм. Еще Бейли Л. - Изучаем SQL (Бестселлеры O'Reilly) - 2012.pdf неплохая. Если совсем даун, то лучше с нее начать, имхо. Там даже картиночки есть.
>>35504
Помню другую книгу из этой серии не стал брать только из за того что там какой то урод был изображён.
Помню другую книгу из этой серии не стал брать только из за того что там какой то урод был изображён.
можно ли ограничить колво записей для айди, который лежит в wherein?
ну допустим
select * from foo where id in bar, bar2
допустим на каждый из них дает 10, а нужно три (какой нить дистинкт с лимитом мб?)
ну допустим
select * from foo where id in bar, bar2
допустим на каждый из них дает 10, а нужно три (какой нить дистинкт с лимитом мб?)
>>36335
При помощи count?
При помощи count?
>>36344
mariadb
mariadb
Аноны, задача такова - запросом дописать в определенном количестве текстовых ячеек, в которых текст разной длины, в конце строки дополнительную информацию.
Подскажите пожалуйста как это реализовать?
Т.е. есть "столбец" с тектстовыми ячейками. В них нужно дописать доп данные.
Подскажите пожалуйста как это реализовать?
Т.е. есть "столбец" с тектстовыми ячейками. В них нужно дописать доп данные.
>>36690
Не совсем понял что ты хочешь, но наверное RIGHT
Не совсем понял что ты хочешь, но наверное RIGHT
>>37049
Что такое one off by error, я не понял.
Но логично, что клиент не знает, когда перестать опрашивать, так что придется спрашивать до тех пор, пока запрос не вернет кол-во строк меньше, чем указано в LIMIT. Ну и, как я понимаю, если в таблице число строк кратно указанному в LIMIT (1000), например, 2 тыщи, то тебе придется 3 раза выполнить запрос вместо 2, чтоб понять, что больше ничего нет.
Что такое one off by error, я не понял.
Но логично, что клиент не знает, когда перестать опрашивать, так что придется спрашивать до тех пор, пока запрос не вернет кол-во строк меньше, чем указано в LIMIT. Ну и, как я понимаю, если в таблице число строк кратно указанному в LIMIT (1000), например, 2 тыщи, то тебе придется 3 раза выполнить запрос вместо 2, чтоб понять, что больше ничего нет.
>>33827
Это как бы два разных профиля. Учи либо первое, либо второе. Я с командой работаю на хадупе, так про гринплюм только слышал. Коллеги работают чаще с ораклом.
>В общем, благодаря тебе у меня примерно сформировался стэк в голове, который мне нужно изучить:
>1) hadoop - yarn - spark
>2) postgres + GreenPlum
>После этого можно идти стучаться на галеры или нужно что то ещё?
Это как бы два разных профиля. Учи либо первое, либо второе. Я с командой работаю на хадупе, так про гринплюм только слышал. Коллеги работают чаще с ораклом.
>>37113
https://en.wikipedia.org/wiki/Off-by-one_error
Тут я полагаю намекается, что оффсет может быть некорректен.
Я отбросил этот вариант, потому что с моей точки зрения клиент знает, когда прекратить, как раз благодаря описанному тобой способу.
>Что такое one off by error, я не понял.
https://en.wikipedia.org/wiki/Off-by-one_error
Тут я полагаю намекается, что оффсет может быть некорректен.
> Но логично, что клиент не знает
Я отбросил этот вариант, потому что с моей точки зрения клиент знает, когда прекратить, как раз благодаря описанному тобой способу.
>>37134
Пошёл нахуй, пидарас
Пошёл нахуй, пидарас
>>37126
Блэт, ну я так понял Hadoop нужен что бы просто кучу данных собрать, а GreenPlum и прочие DWH нужны, что бы данные было проще анализировать. И для того, что бы перетащить данные из Hadoop или реляционки в DWH строится ETL. По крайне мере в вакансиях на Дата Инженера требует знания как Hadoop, так и OLAP с DWH. SQL тоже. Хуй знает, чем там в реальности нужно будет заниматься.
Кстати говоря, обязательно ли для освоения Hadoop арендовать сервак с огромным HDD(SDD)? А то брать больше 30Г как то жаба душит, может для обучения и их хватит?
>Это как бы два разных профиля. Учи либо первое, либо второе. Я с командой работаю на хадупе, так про гринплюм только слышал. Коллеги работают чаще с ораклом.
Блэт, ну я так понял Hadoop нужен что бы просто кучу данных собрать, а GreenPlum и прочие DWH нужны, что бы данные было проще анализировать. И для того, что бы перетащить данные из Hadoop или реляционки в DWH строится ETL. По крайне мере в вакансиях на Дата Инженера требует знания как Hadoop, так и OLAP с DWH. SQL тоже. Хуй знает, чем там в реальности нужно будет заниматься.
Кстати говоря, обязательно ли для освоения Hadoop арендовать сервак с огромным HDD(SDD)? А то брать больше 30Г как то жаба душит, может для обучения и их хватит?
>>37783
Нагулил что у них есть бесплатный сервак на год, ну там как раз 30ГБ, это хватит?
Ещё я слышал, что если занять места больше 30ГБ или нагрузить сервак сильнее дозволенного, то у тебя деньги начнут снимать, без спроса.
Нагулил что у них есть бесплатный сервак на год, ну там как раз 30ГБ, это хватит?
Ещё я слышал, что если занять места больше 30ГБ или нагрузить сервак сильнее дозволенного, то у тебя деньги начнут снимать, без спроса.
>>37840
А вдруг я за ночь заполнится диск на несколько террабайт и придёт счёт на 1000 долларов. И что делать?
А вдруг я за ночь заполнится диск на несколько террабайт и придёт счёт на 1000 долларов. И что делать?
>>37844
Так это ведь пиндосия, а ты в пидорашке. Что они тебе сделают? Посадят? Штрафанут? Счёт в сбере залочат?
Так это ведь пиндосия, а ты в пидорашке. Что они тебе сделают? Посадят? Штрафанут? Счёт в сбере залочат?
>>37049
Вот тут
https://use-the-index-luke.com/no-offset
читал что offset это медленна и вообще так нельзя. У меня просто в голове не укладывается по-моему это какой то полный пиздец. Но такое впечатление у меня от всего свитеромирка так что.. просто оставлю свои пять копеек, может это кому то будет полезным.
Вот тут
https://use-the-index-luke.com/no-offset
читал что offset это медленна и вообще так нельзя. У меня просто в голове не укладывается по-моему это какой то полный пиздец. Но такое впечатление у меня от всего свитеромирка так что.. просто оставлю свои пять копеек, может это кому то будет полезным.
>>37752
собрать и обработать. Попробуй провести матчинг 2-5 таблиц в оракле, не наебнув там все. В хадупе же ты просто меняешь размер контейнера в зависимости от объема данных и все.
Нет. Поставь себе виртуальный сервак, погугли дистрибутив cloudera VM quickstart
Тебе не нужно дома для обучения 3 петабайта. Наполни 3-5 таблиц 10 стоками и напиши на скале проект, который матчит данные из них в новую таблицу, сбилди джарник и залей в VM, запусти, посмотри в ярне как работает. На этом можешь закончить. Я на деве тем же самым занимаюсь. Хорошо, если в таблице 50 строк, а не 0, как бывает. А на проде там терабайты лежат, вполне себе.
На собезе расскажешь, уже плюсом будет.
>Hadoop нужен что бы просто кучу данных собрать
собрать и обработать. Попробуй провести матчинг 2-5 таблиц в оракле, не наебнув там все. В хадупе же ты просто меняешь размер контейнера в зависимости от объема данных и все.
>Кстати говоря, обязательно ли для освоения Hadoop арендовать сервак с огромным HDD(SDD)? А то брать больше 30Г как то жаба душит, может для обучения и их хватит?
Нет. Поставь себе виртуальный сервак, погугли дистрибутив cloudera VM quickstart
Тебе не нужно дома для обучения 3 петабайта. Наполни 3-5 таблиц 10 стоками и напиши на скале проект, который матчит данные из них в новую таблицу, сбилди джарник и залей в VM, запусти, посмотри в ярне как работает. На этом можешь закончить. Я на деве тем же самым занимаюсь. Хорошо, если в таблице 50 строк, а не 0, как бывает. А на проде там терабайты лежат, вполне себе.
На собезе расскажешь, уже плюсом будет.
>>33827
Не верю, что на галерах нужен хадуп и прочая аналитика, это же продуктовая тема. На галерах просто реляционки или простенькие in-memory kv типо редиса или мемкеша для кеширования.
Не верю, что на галерах нужен хадуп и прочая аналитика, это же продуктовая тема. На галерах просто реляционки или простенькие in-memory kv типо редиса или мемкеша для кеширования.
>>33827
Если хочешь опыта набраться и вкусить всю прелесть хранилищ, сюда попробуй влезть хотя-бы стажором, чтоб на жилье хватало и жрачку, пол года-год пересидеть.
Сам туда пойду скорее всего
https://hh.ru/vacancy/32678281
Если хочешь опыта набраться и вкусить всю прелесть хранилищ, сюда попробуй влезть хотя-бы стажором, чтоб на жилье хватало и жрачку, пол года-год пересидеть.
Сам туда пойду скорее всего
https://hh.ru/vacancy/32678281
>>40032
В продолжение. Хранилище только начиначет строится. А это самый смак, на все грабли наступить, самое оно. Плюс там куча интеграций и ораклы и хадупы. Я думаю работы там года на 3 не меньше
В продолжение. Хранилище только начиначет строится. А это самый смак, на все грабли наступить, самое оно. Плюс там куча интеграций и ораклы и хадупы. Я думаю работы там года на 3 не меньше
>>40032
Блэт, нихочу в москву ехать, я в дс2 уже нормально устроился и щас всё сначала начинать. Охуенно, чо. Да и из текущей галеры я щас свалить не могу.
Блэт, нихочу в москву ехать, я в дс2 уже нормально устроился и щас всё сначала начинать. Охуенно, чо. Да и из текущей галеры я щас свалить не могу.
>>40614
Ну смотри сам, я для себя вообще режим кочевника выработал - год два на проект, и на съебы. По моим наблюдениям, вся веселуха обычно на старте, потом когда решение стабилизируется начинается болото: скрамы, митинги бесконечные, однотипные задачи.
Ну смотри сам, я для себя вообще режим кочевника выработал - год два на проект, и на съебы. По моим наблюдениям, вся веселуха обычно на старте, потом когда решение стабилизируется начинается болото: скрамы, митинги бесконечные, однотипные задачи.
>>41015
да это ваще пздц
Можно устроиться и потом месяц выбивать себе рабочее место
Я слышал историю как чувак так и не успел получить себе комп до увольнения
да это ваще пздц
Можно устроиться и потом месяц выбивать себе рабочее место
Я слышал историю как чувак так и не успел получить себе комп до увольнения
>>41019
Охуенный ты опыт там приобретешь
Другая история:
- работали со сбертехом
- предложили написать им скрипт инсталляции
- они отказались
- написали им инструкцию, подробную, для дебилов
- выполнили с ошибкой(ами) на каждом шаге
Охуенный ты опыт там приобретешь
Другая история:
- работали со сбертехом
- предложили написать им скрипт инсталляции
- они отказались
- написали им инструкцию, подробную, для дебилов
- выполнили с ошибкой(ами) на каждом шаге
Аноны, у меня проблема:
Использую DB Browser for SQLite. Удаляю таблицу с данными. Размер файла не уменьшается. При открытии фалйа через ноутпад вижу удаленную таблицу с удаленными данными. Приходится конвертировать импортируя .db в .sql и экспортируя обратно, так как при таком действии можно выбирать нужные таблицы.
Что я делаю не так? Или всё так и по-другому никак? Что я не понимаю в работе sql и почему данные с таблицей остаются в файле после удаления?
Использую DB Browser for SQLite. Удаляю таблицу с данными. Размер файла не уменьшается. При открытии фалйа через ноутпад вижу удаленную таблицу с удаленными данными. Приходится конвертировать импортируя .db в .sql и экспортируя обратно, так как при таком действии можно выбирать нужные таблицы.
Что я делаю не так? Или всё так и по-другому никак? Что я не понимаю в работе sql и почему данные с таблицей остаются в файле после удаления?
>>41588
https://www.sqlite.org/lang_vacuum.html
Тащемта, то, что файл остается большим - это обычно плюс, нежели минус.
Предполагается, что новые данные появятся после удаления.
Это типично во всех движках.
Дешевле пометить страницы как удаленные и потом поверх них писать, чем .. что ты предлагаешь? нулями забивать?
https://www.sqlite.org/lang_vacuum.html
Тащемта, то, что файл остается большим - это обычно плюс, нежели минус.
Предполагается, что новые данные появятся после удаления.
> При открытии фалйа через ноутпад вижу удаленную таблицу с удаленными данными.
Это типично во всех движках.
Дешевле пометить страницы как удаленные и потом поверх них писать, чем .. что ты предлагаешь? нулями забивать?
>>41598
У меня база используется в программе для смартфона, размер программы 100 мегабайт, вместо 20, это минус, например.
В любом случае большое спасибо:
Поставил фулл.
У меня база используется в программе для смартфона, размер программы 100 мегабайт, вместо 20, это минус, например.
В любом случае большое спасибо:
>Если SQLite не работает в режиме «auto_vacuum = FULL», когда большой объем данных удаляется из файла базы данных, он оставляет пустое пространство или «свободные» страницы базы данных. Это означает, что файл базы данных может быть больше, чем строго необходимо. Запуск VACUUM для восстановления базы данных освобождает это пространство и уменьшает размер файла базы данных.
Поставил фулл.
>>41628
Ты поосторожнее с автовакуумами
Лучше периодически проверять и делать принудительно, чем на автомате
Автовакуумы обычно приводят к тому, что все данные валяются хрен знает как : кусочек того, хвост другого, тут еще какая-то х-ня
Впрочем, если база мелкая - то пофигу
Ты поосторожнее с автовакуумами
Лучше периодически проверять и делать принудительно, чем на автомате
Автовакуумы обычно приводят к тому, что все данные валяются хрен знает как : кусочек того, хвост другого, тут еще какая-то х-ня
Впрочем, если база мелкая - то пофигу
>>15028868
Приведи лучше ты пример хайлоад проекта с реляционной бд в качестве рантайм хранилища
>>02886
Я тоже старый пердун
Если ты думаешь, что NoSQL - это какой-то писк моды, то ты от жизни отстал
Можешь свой пафос уносить
Я тоже старый пердун
Если ты думаешь, что NoSQL - это какой-то писк моды, то ты от жизни отстал
Можешь свой пафос уносить
>>16588
Если знаешь английский то cmu лучший курс по базам данных.
нагуглить эти три три буквы и найдёшь курс Andy Pavlo
Если знаешь английский то cmu лучший курс по базам данных.
нагуглить эти три три буквы и найдёшь курс Andy Pavlo
>>40915
СберТех был кадровой помойкой какое то время назад
С новым директором они взяли курс на выезд из помойки но люди к сожалению остались. Туда можно сходить и начать карьеру, но на собеседованиях в нормальных конторах считает юных сбертеховцев оверпрайснутыми даунами. Потому что Джуно куа 70к не стоит после года работы. Даже в 2019. Даже девелопер столько не стоит. (В среднем)
Поэтому если не прилип жопой к стулу и обучаешься (это там вроде можно делать) то шанс вырваться есть. Главное не охуевать с самооценкой потом.
СберТех был кадровой помойкой какое то время назад
С новым директором они взяли курс на выезд из помойки но люди к сожалению остались. Туда можно сходить и начать карьеру, но на собеседованиях в нормальных конторах считает юных сбертеховцев оверпрайснутыми даунами. Потому что Джуно куа 70к не стоит после года работы. Даже в 2019. Даже девелопер столько не стоит. (В среднем)
Поэтому если не прилип жопой к стулу и обучаешься (это там вроде можно делать) то шанс вырваться есть. Главное не охуевать с самооценкой потом.
>>34842
nexign
nexign
52 Кб, 793x1118Вот есть такая база. В wp_posts хранятся и посты, и их ревизии, и часть инфы о загруженных файлах, и какая-то история изменений темы оформления сайта что ли, и ещё хрен знает, что. В wp_postmeta хранится инфа, связанная с постами, другая часть инфы о загруженных файлах и вообще что угодно.
Опуская проблему полного отсутствия FK, есть два вопроса.
1. На сколько строк нужно загадить wp_posts, чтобы поиск по post_name (с индексом) стал заметно тормозить?
2. На сколько строк нужно загадить wp_postmeta, чтобы выбор по post_id стал заметно тормозить?
MariaDB 10.X. Допустим, всё лежит на SSD. Проц - 2x2GHz.
Опуская проблему полного отсутствия FK, есть два вопроса.
1. На сколько строк нужно загадить wp_posts, чтобы поиск по post_name (с индексом) стал заметно тормозить?
2. На сколько строк нужно загадить wp_postmeta, чтобы выбор по post_id стал заметно тормозить?
MariaDB 10.X. Допустим, всё лежит на SSD. Проц - 2x2GHz.
>>40915
до 12 грейда - рук направления - можно спокойно расти
выше, всякие исполнительные директора - там уже хуй
но у тебя на 12-ом уже будет под 350-к, сколько тебе в других местах хуй дадут
чего еще надо?
>Потому что там есть ограничения на карьерный рост и на рост зп.
до 12 грейда - рук направления - можно спокойно расти
выше, всякие исполнительные директора - там уже хуй
но у тебя на 12-ом уже будет под 350-к, сколько тебе в других местах хуй дадут
чего еще надо?
Привет всем.
Так вышло, что после полутора лет эникейства мне в экстренном почти порядке пришлось вкатываться в SQL Server (как мешком по голове).
Сегодня написал тестовое задание, будет ещё одно, мб тут совета спрошу, если не разберусь.
Что хотел спросить.
Посидев в этой говноконторе в качестве "Инженера баз данных" опционально год-два-три, смогу ли я рассчитывать на трудоустройство в другую контору, имея на руках эти пару лет опыта? (при этом не имея вышки).
И вообще насколько эта перспективная отрасль? Или придётся неизбежно вкатываться в другие языки погромирования, чтобы продвинуться дальше?
Так вышло, что после полутора лет эникейства мне в экстренном почти порядке пришлось вкатываться в SQL Server (как мешком по голове).
Сегодня написал тестовое задание, будет ещё одно, мб тут совета спрошу, если не разберусь.
Что хотел спросить.
Посидев в этой говноконторе в качестве "Инженера баз данных" опционально год-два-три, смогу ли я рассчитывать на трудоустройство в другую контору, имея на руках эти пару лет опыта? (при этом не имея вышки).
И вообще насколько эта перспективная отрасль? Или придётся неизбежно вкатываться в другие языки погромирования, чтобы продвинуться дальше?
Есть таблица из ~900 строк, хочу делать SELECT по полю char(4). Насколько быстро оно будет работать? Стоит ли добавить индекс?
>>44095
Какой селект ты хочешь сделать?
Where my_column like '%kaka%'?
Тогда индекс не поможет
Where my_column like = 'kaka'?
Тогда можешь сделать. Другой вопрос, что 900 строк - что с индексом, что без индекса, будет бытро искать, потому что размер - ни о чем.
Какой селект ты хочешь сделать?
Where my_column like '%kaka%'?
Тогда индекс не поможет
Where my_column like = 'kaka'?
Тогда можешь сделать. Другой вопрос, что 900 строк - что с индексом, что без индекса, будет бытро искать, потому что размер - ни о чем.
>>44139
Без процентов, точное соответствие.
На каких размерах нужно чесать репу? 900000?
> Какой селект ты хочешь сделать?
Без процентов, точное соответствие.
> Другой вопрос, что 900 строк - что с индексом, что без индекса, будет бытро искать, потому что размер - ни о чем
На каких размерах нужно чесать репу? 900000?
>>44154
Зависит от дисков, на которых у тебя БД сидит, от СУБД тоже, а так же от внутренних правил.
Ну например, у тебя приложение с правилами ОТКАЗОУСТОЙЧИВОСТИ: время ответа не более 0.5 секунды.
Вот твой запрос работает нормлаьно
Завтра ты 100 000 строк заинсертил, уже 0.9 секунды отвечает - ты это мониторишь, понимаешь, что пора индекс добавить.
>900000?
Зависит от дисков, на которых у тебя БД сидит, от СУБД тоже, а так же от внутренних правил.
Ну например, у тебя приложение с правилами ОТКАЗОУСТОЙЧИВОСТИ: время ответа не более 0.5 секунды.
Вот твой запрос работает нормлаьно
Завтра ты 100 000 строк заинсертил, уже 0.9 секунды отвечает - ты это мониторишь, понимаешь, что пора индекс добавить.
>>44034
Хрюши расписывают в вакансии что нужно от соискателя.
Хрюши расписывают в вакансии что нужно от соискателя.
>>45042
1. Меньше кода
2. план запроса - баз самоджойнов, если не юзаешь индексы, то получается быстрее
Ну и интересно посмотреть, как ты прорнжируешь строчки без оконной функции, например, так:
id, dt, rank
1, 20190101, 1
2, 20190101, 1
3, 20190101, 1
4, 20190108, 2
5. 20190108, 2
6, 20190111, 3
1. Меньше кода
2. план запроса - баз самоджойнов, если не юзаешь индексы, то получается быстрее
Ну и интересно посмотреть, как ты прорнжируешь строчки без оконной функции, например, так:
id, dt, rank
1, 20190101, 1
2, 20190101, 1
3, 20190101, 1
4, 20190108, 2
5. 20190108, 2
6, 20190111, 3
Сап БДач, есть одна БД.
Напомни мне дебилу почему
SELECT ...
FROM [dbo].[fct_cheque] as f
inner join dim_goods as g
on g.good_id = f.good_id
inner join [dim_stores] as s
on s.store_id = f.store_id
inner join dim_date as d
on d.did = f.date_id
inner join dbo.dim_cash_register as cr
on cr.cash_register_id = f.cash_register_id
where date_id between @date_from_int and @date_to_int
and g.group_name = @good_group_name
Вытаскивает не все данные, а вот в таком виде:
SELECT ...
FROM [dbo].[fct_cheque] as f
LEFT JOIN (SELECT DISTINCT cash_register_id FROM [dbo].[dim_cash_register]) as cr
on f.cash_register_id=cr.cash_register_id
LEFT JOIN [dbo].[dim_date] as d
ON d.did=f.date_id
LEFT JOIN (SELECT DISTINCT [good_id],[good_name],[group_id],[group_name]
FROM [dbo].[dim_goods]) as g
on f.good_id=g.good_id
LEFT JOIN [dbo].[dim_stores] as s
on s.store_id=f.store_id
where date_id between @date_from_int and @date_to_int
and g.group_name=@good_group_name
Выдаёт всё как надо.
Напомни мне дебилу почему
SELECT ...
FROM [dbo].[fct_cheque] as f
inner join dim_goods as g
on g.good_id = f.good_id
inner join [dim_stores] as s
on s.store_id = f.store_id
inner join dim_date as d
on d.did = f.date_id
inner join dbo.dim_cash_register as cr
on cr.cash_register_id = f.cash_register_id
where date_id between @date_from_int and @date_to_int
and g.group_name = @good_group_name
Вытаскивает не все данные, а вот в таком виде:
SELECT ...
FROM [dbo].[fct_cheque] as f
LEFT JOIN (SELECT DISTINCT cash_register_id FROM [dbo].[dim_cash_register]) as cr
on f.cash_register_id=cr.cash_register_id
LEFT JOIN [dbo].[dim_date] as d
ON d.did=f.date_id
LEFT JOIN (SELECT DISTINCT [good_id],[good_name],[group_id],[group_name]
FROM [dbo].[dim_goods]) as g
on f.good_id=g.good_id
LEFT JOIN [dbo].[dim_stores] as s
on s.store_id=f.store_id
where date_id between @date_from_int and @date_to_int
and g.group_name=@good_group_name
Выдаёт всё как надо.
Сап БДач, есть одна БД.
Напомни мне дебилу почему
SELECT ...
FROM [dbo].[fct_cheque] as f
inner join dim_goods as g
on g.good_id = f.good_id
inner join [dim_stores] as s
on s.store_id = f.store_id
inner join dim_date as d
on d.did = f.date_id
inner join dbo.dim_cash_register as cr
on cr.cash_register_id = f.cash_register_id
where date_id between @date_from_int and @date_to_int
and g.group_name = @good_group_name
Вытаскивает не все данные, а вот в таком виде:
SELECT ...
FROM [dbo].[fct_cheque] as f
LEFT JOIN (SELECT DISTINCT cash_register_id FROM [dbo].[dim_cash_register]) as cr
on f.cash_register_id=cr.cash_register_id
LEFT JOIN [dbo].[dim_date] as d
ON d.did=f.date_id
LEFT JOIN (SELECT DISTINCT [good_id],[good_name],[group_id],[group_name]
FROM [dbo].[dim_goods]) as g
on f.good_id=g.good_id
LEFT JOIN [dbo].[dim_stores] as s
on s.store_id=f.store_id
where date_id between @date_from_int and @date_to_int
and g.group_name=@good_group_name
Выдаёт всё как надо.
Напомни мне дебилу почему
SELECT ...
FROM [dbo].[fct_cheque] as f
inner join dim_goods as g
on g.good_id = f.good_id
inner join [dim_stores] as s
on s.store_id = f.store_id
inner join dim_date as d
on d.did = f.date_id
inner join dbo.dim_cash_register as cr
on cr.cash_register_id = f.cash_register_id
where date_id between @date_from_int and @date_to_int
and g.group_name = @good_group_name
Вытаскивает не все данные, а вот в таком виде:
SELECT ...
FROM [dbo].[fct_cheque] as f
LEFT JOIN (SELECT DISTINCT cash_register_id FROM [dbo].[dim_cash_register]) as cr
on f.cash_register_id=cr.cash_register_id
LEFT JOIN [dbo].[dim_date] as d
ON d.did=f.date_id
LEFT JOIN (SELECT DISTINCT [good_id],[good_name],[group_id],[group_name]
FROM [dbo].[dim_goods]) as g
on f.good_id=g.good_id
LEFT JOIN [dbo].[dim_stores] as s
on s.store_id=f.store_id
where date_id between @date_from_int and @date_to_int
and g.group_name=@good_group_name
Выдаёт всё как надо.
>>45667
Дурацкий блокнот++, вот корректная версия первого запроса
FROM [dbo].[fct_cheque] as f
inner join dim_goods as g
on g.good_id = f.good_id
inner join [dim_stores] as s
on s.store_id = f.store_id
inner join dim_date as d
on d.did = f.date_id
inner join dbo.dim_cash_register as cr
on cr.cash_register_id = f.cash_register_id
where date_id between @date_from_int and @date_to_int
and g.group_name = @good_group_name
Дурацкий блокнот++, вот корректная версия первого запроса
FROM [dbo].[fct_cheque] as f
inner join dim_goods as g
on g.good_id = f.good_id
inner join [dim_stores] as s
on s.store_id = f.store_id
inner join dim_date as d
on d.did = f.date_id
inner join dbo.dim_cash_register as cr
on cr.cash_register_id = f.cash_register_id
where date_id between @date_from_int and @date_to_int
and g.group_name = @good_group_name
>>45668
Потому-что в первом все джоины inner join, поэтому теряются значения с 0. Т.е. Он хочет джоинить А на Б, но А равно нулю, образно говоря продавец Коля нихуя не продал, и у него 0 в графе продажи, и иннер отбрасывает такие поля. Во втором запросе у тебя послежний джоин левый, соотвественно значения с нулями сохраняются.
Потому-что в первом все джоины inner join, поэтому теряются значения с 0. Т.е. Он хочет джоинить А на Б, но А равно нулю, образно говоря продавец Коля нихуя не продал, и у него 0 в графе продажи, и иннер отбрасывает такие поля. Во втором запросе у тебя послежний джоин левый, соотвественно значения с нулями сохраняются.
>>45781
Проблема в том, что во втором продаётся больше (и с фактическим числом продаж сходится) и я не понимаю как.
Проблема в том, что во втором продаётся больше (и с фактическим числом продаж сходится) и я не понимаю как.
>>45828
ну у тебя во втором ещё подзапросы в джоине. Вобще я конечно не эксперт но это какой-то говнокод, столько лефтджоинов подряд не делают, при том судя по подзапросу, намерено сокращается число строк, чего в первом запросе не делают, так что рискну предположить что все что это сделано чтобы с первого лефт джоина не тащить говно. Должно быть INNER-INNER-....-LEFT например. Хотя конечно может идея как раз в этом, чтоб протащить все пустые строки до последнего, но всё равно тупость какая-то.
ну у тебя во втором ещё подзапросы в джоине. Вобще я конечно не эксперт но это какой-то говнокод, столько лефтджоинов подряд не делают, при том судя по подзапросу, намерено сокращается число строк, чего в первом запросе не делают, так что рискну предположить что все что это сделано чтобы с первого лефт джоина не тащить говно. Должно быть INNER-INNER-....-LEFT например. Хотя конечно может идея как раз в этом, чтоб протащить все пустые строки до последнего, но всё равно тупость какая-то.
>>45874
Как то так например
FROM [dbo].[fct_cheque] as f
inner join dim_goods as g
on g.good_id = f.good_id
inner join [dim_stores] as s
on s.store_id = f.store_id
inner join dim_date as d
on d.did = f.date_id
right join dbo.dim_cash_register as cr
on cr.cash_register_id = f.cash_register_id
where date_id between @date_from_int and @date_to_int
and g.group_name = @good_group_name
Как то так например
FROM [dbo].[fct_cheque] as f
inner join dim_goods as g
on g.good_id = f.good_id
inner join [dim_stores] as s
on s.store_id = f.store_id
inner join dim_date as d
on d.did = f.date_id
right join dbo.dim_cash_register as cr
on cr.cash_register_id = f.cash_register_id
where date_id between @date_from_int and @date_to_int
and g.group_name = @good_group_name
>>45877
Но опять же я не знаю из какой таблицы нужны пустые значения, так что предположу что из последней, но это похоже не так, если жоины таки левые.
Но опять же я не знаю из какой таблицы нужны пустые значения, так что предположу что из последней, но это похоже не так, если жоины таки левые.
Не понимаю что за хуйня. При попытке добавить запись в таблицу пишет
Я пробовал отключать проверку внешних ключей
Но ошибка остается.
>Error: Cannot add or update a child row: a foreign key constraint fails (`solach`.`info_matches`, CONSTRAINT `info_matches_ibfk_1` FOREIGN KEY (`id_match`) REFERENCES `matches` (`id`))
Я пробовал отключать проверку внешних ключей
>SET foreign_key_checks=0
Но ошибка остается.
>>46043
Вообще не понял к чему ты это написал. Да, у меня связь один ко многим. Вторая таблица содержит поле с внешним ключом, которое может повторяться, а в первой таблице это поле уникальное.
>Связь один ко многим
Вообще не понял к чему ты это написал. Да, у меня связь один ко многим. Вторая таблица содержит поле с внешним ключом, которое может повторяться, а в первой таблице это поле уникальное.
>>46040
Наверное, еще надо уточнить, что все запросы внутри транзакции выполняются. Но там же вроде есть буфер какой-то, который временно считает, что все запросы как-бы выполнены. Т.е. если сначала добавить запись в первую таблицу с первичным ключом внутри транзакции, а потом сослаться на нее, добавив во вторую таблицу по внешнему ключу ДО ВЫПОЛНЕНИЯ коммита, то во время добавления записи во вторую таблицу запись в первой будет в этом временном буфере, если не было роллбэка. Так ведь? Но у меня почему-то не добавляет запись, даже с выключенной проверкой ключей.
Наверное, еще надо уточнить, что все запросы внутри транзакции выполняются. Но там же вроде есть буфер какой-то, который временно считает, что все запросы как-бы выполнены. Т.е. если сначала добавить запись в первую таблицу с первичным ключом внутри транзакции, а потом сослаться на нее, добавив во вторую таблицу по внешнему ключу ДО ВЫПОЛНЕНИЯ коммита, то во время добавления записи во вторую таблицу запись в первой будет в этом временном буфере, если не было роллбэка. Так ведь? Но у меня почему-то не добавляет запись, даже с выключенной проверкой ключей.
>>46047
Так удаляй строки с первичным ключом сначала из дочерей таблицы, а потом из главной.
С такими вопросами тебе нужно бросать своё хобби
Так удаляй строки с первичным ключом сначала из дочерей таблицы, а потом из главной.
С такими вопросами тебе нужно бросать своё хобби
>>46069
Нахуя мне их удалять? Мне их вставить надо. Вставить в 1 таблицу, вставить во 2 таблицу, ссылаясь на вставленную запись в 1 таблицу, которая еще не была закоммичена, ибо ценность эти данные представляют только вместе. Для того и была использована транзакция. Но при добавлении во 2 таблицу, мне пишет, что такой записи в 1 таблице нет.
Нахуя мне их удалять? Мне их вставить надо. Вставить в 1 таблицу, вставить во 2 таблицу, ссылаясь на вставленную запись в 1 таблицу, которая еще не была закоммичена, ибо ценность эти данные представляют только вместе. Для того и была использована транзакция. Но при добавлении во 2 таблицу, мне пишет, что такой записи в 1 таблице нет.
Пиздец, какое-то шизло тут сидит, несет хуйню с умным видом, не разобравшись нихуя в вопросе и еще пиздит что-то про то, кому стать программистом, а кому нет... Ебало его представили?
21 Кб, 238x300>>46102
Нет, чел, тупой - ты. Потому что ты меня не слышишь нихуя. В транзакции не работает
START TRANSACTION;
INSERT INTO t1 VALUES id='1', name='name';
INSERT INTO t2 VALUES id_t1='1', something='something';
COMMIT;
где id - первичный, id_t1 - внешний
А ошибка эта не говорит нихуя, кроме того, что id=1 в t1 нету. А теперь иди на хуй, ты меня заебал уже душить своей тупостью и выебонами, чмо. Кстати, я тут нагуглил твое ебало (пик)
Нет, чел, тупой - ты. Потому что ты меня не слышишь нихуя. В транзакции не работает
START TRANSACTION;
INSERT INTO t1 VALUES id='1', name='name';
INSERT INTO t2 VALUES id_t1='1', something='something';
COMMIT;
где id - первичный, id_t1 - внешний
А ошибка эта не говорит нихуя, кроме того, что id=1 в t1 нету. А теперь иди на хуй, ты меня заебал уже душить своей тупостью и выебонами, чмо. Кстати, я тут нагуглил твое ебало (пик)
272 Кб, 648x503>START TRANSACTION;
>INSERT INTO t1 VALUES id='1', name='name';
>INSERT INTO t2 VALUES id_t1='1', something='something';
>COMMIT;
Ну и хули ты там скукожился, чмондель от мира ит? Если ты так отреагировал на синтаксис инсерта, то я специально его сделал коротким и "не рабочим".
>>46122
Тебе нужно почитать про целостность и смысл транзакций.
Правда лучше бросить это занятие прямо сейчас
Тебе нужно почитать про целостность и смысл транзакций.
Правда лучше бросить это занятие прямо сейчас
Нет, чел, мне нужно оформить записи в две таблицы, а со своей целостностью ты идешь на хуй, ибо я читал это все, и это не имеет никакого отношения к моей проблеме.
>>46127
Хуёво читал, раз весь тред так обосрался.
Хуёво читал, раз весь тред так обосрался.
>>46130
И зачем он там? Если второй инсерт не выполнится, то первый останется куском не нужно говна в бд. Или надо еще состояние запоминать перед первым коммитом и откатывать к нему?
И зачем он там? Если второй инсерт не выполнится, то первый останется куском не нужно говна в бд. Или надо еще состояние запоминать перед первым коммитом и откатывать к нему?
>>46135
И вообще, я выше писал где-то про временный буфер. Я где-то читал про него, потому и думал, что никакие промежуточные коммиты в контексте одной транзакции не нужны.
И вообще, я выше писал где-то про временный буфер. Я где-то читал про него, потому и думал, что никакие промежуточные коммиты в контексте одной транзакции не нужны.
>>46141
Да иди ты на хуй, уебище. Не умеешь находить общий язык с людьми - сиди и дрочи. На хуй ты вообще пишешь что-то? Какова тут твоя цель? Просто скройся.
Ору с этого дауна, который решил посеменить, разлогинившись. Пидарас пасскодовский. Хррртьфу на еблет твой...
Да иди ты на хуй, уебище. Не умеешь находить общий язык с людьми - сиди и дрочи. На хуй ты вообще пишешь что-то? Какова тут твоя цель? Просто скройся.
Ору с этого дауна, который решил посеменить, разлогинившись. Пидарас пасскодовский. Хррртьфу на еблет твой...
Мне стало интересно, почему не работает, бля и правда ответ тому Антону гуглиться на первой странице. Ну ты и валенок блядь, ещё на анонов пиздишь
>>46348
Я хочу тебе обоссать твое ебальце, глупыш
Я хочу тебе обоссать твое ебальце, глупыш
попрошу ногами не пиздить, если спрашиваю хуйню. В общем есть ли смысл создавать кучу отдельных таблиц для одного типа данных?
Вот пример: сообщения ВК на мобиле, для каждого чатика создается отдельная таблица, хранящая сообщения из чата.. или правильней все сообщения пихнуть в одну таблицу с внешним внешним ключом?
Вот пример: сообщения ВК на мобиле, для каждого чатика создается отдельная таблица, хранящая сообщения из чата.. или правильней все сообщения пихнуть в одну таблицу с внешним внешним ключом?
>>46409
Эй, хуета, я вроде русским языком сказал: покажи мне этот ответ, который лежит на первой странице и решает мою проблему. Если ты как сучка поджал хвост, опасаясь быть обоссаным мною итт, то просто пиздак прихлопни и сиди тише воды, ниже травы. Справишься хоть с чем-то из этого? Или продолжишь пиздеть без повода?
Эй, хуета, я вроде русским языком сказал: покажи мне этот ответ, который лежит на первой странице и решает мою проблему. Если ты как сучка поджал хвост, опасаясь быть обоссаным мною итт, то просто пиздак прихлопни и сиди тише воды, ниже травы. Справишься хоть с чем-то из этого? Или продолжишь пиздеть без повода?
>>46415
Поздравляю. Мощная струя едреной мочи летит прямо тебе в ебало. Чел, унеси свою хуйню, которая вообще не имеет никакого отношения к проблеме или иди перечитывай мой самый первый пост, где я был еще добрым. Мне похуй как ты это делать будешь, я хз, проси там модеров что ли... Но только чтобы я не видел этой хуйни тут.
Поздравляю. Мощная струя едреной мочи летит прямо тебе в ебало. Чел, унеси свою хуйню, которая вообще не имеет никакого отношения к проблеме или иди перечитывай мой самый первый пост, где я был еще добрым. Мне похуй как ты это делать будешь, я хз, проси там модеров что ли... Но только чтобы я не видел этой хуйни тут.
>>46418
Ты или удаляешь констрейнт или делаешь промежуточный коммит.
Неужели ты правда не способен этого понять?
Ты или удаляешь констрейнт или делаешь промежуточный коммит.
Неужели ты правда не способен этого понять?
>>46416
Я понимаю, что вижу какого таракана, который на уровне земли что то пищит, переводит стрелки, а я его даже не слышу. Потому что мои капли мочи громче бьются о пол, пока мимокрок выше наслаждается своей дозой.
Я понимаю, что вижу какого таракана, который на уровне земли что то пищит, переводит стрелки, а я его даже не слышу. Потому что мои капли мочи громче бьются о пол, пока мимокрок выше наслаждается своей дозой.
>>46422
Как ты еще пластмассу или пенопласт будучи таким тупым есть не начал?
Как ты еще пластмассу или пенопласт будучи таким тупым есть не начал?
>>46421
Вот так да... Ахуеть? Правда? Об этом написано где-то было в том "ответе"? Интересно-интересно... А вот вопрос такой, а почему с констрейнтом нельзя-то? Получается, я то был прав насчет видимости результатов запросов в контексте транзакции? Но вот только что-то никто не дополнил мою мысль, да? Еее для вас как буд-то и не было. А теперь, выясняется, что виной-то всему был констрейнт)))))) Хех))) Но да ладно, опять же... Коммит... Знаешь? А я его делал... Вот только в чистом его виде нельзя делать, надо создавать savepoint... Кстати, не подскажешь как его создать в mysql2 модуле для node js? Ты поищи-поищи, наверняка, на первой странице будет ответ. Линканешь мне потом его сюда. Давай...
Вот так да... Ахуеть? Правда? Об этом написано где-то было в том "ответе"? Интересно-интересно... А вот вопрос такой, а почему с констрейнтом нельзя-то? Получается, я то был прав насчет видимости результатов запросов в контексте транзакции? Но вот только что-то никто не дополнил мою мысль, да? Еее для вас как буд-то и не было. А теперь, выясняется, что виной-то всему был констрейнт)))))) Хех))) Но да ладно, опять же... Коммит... Знаешь? А я его делал... Вот только в чистом его виде нельзя делать, надо создавать savepoint... Кстати, не подскажешь как его создать в mysql2 модуле для node js? Ты поищи-поищи, наверняка, на первой странице будет ответ. Линканешь мне потом его сюда. Давай...
>>45879
Там по идее не нужны пустые значения (идёт вывод данных о продажах).
А ещё меня смущают DISTINCT'ы, посмотрел в dim_cash_register - там 23 записи, но касс всего 22 (кассы № 10 нет, а касса № 7 дублируется). Это что-то может объяснить?
В dim_goods с учётом фильтрации WHERE DISTINCT не убирает ничего.
Извиняюсь что я тупой нубас.
Там по идее не нужны пустые значения (идёт вывод данных о продажах).
А ещё меня смущают DISTINCT'ы, посмотрел в dim_cash_register - там 23 записи, но касс всего 22 (кассы № 10 нет, а касса № 7 дублируется). Это что-то может объяснить?
В dim_goods с учётом фильтрации WHERE DISTINCT не убирает ничего.
Извиняюсь что я тупой нубас.
И да, кстати, вот такой вопрос к уебищам, которые что-то пиздели тут. Что думаете насчет этой хуйни?
https://stackoverflow.com/questions/12245599/inserting-mysql-foreign-keys-and-primary-keys-in-a-transaction
Что-то не вяжется да? Чел просто интересуется "сработает ли?", на что получает ответ "да". А у меня что-то вот не выходит ни хуя... Я, наверное, тупой, просто не увидел ответ на первой странице...
https://stackoverflow.com/questions/12245599/inserting-mysql-foreign-keys-and-primary-keys-in-a-transaction
Что-то не вяжется да? Чел просто интересуется "сработает ли?", на что получает ответ "да". А у меня что-то вот не выходит ни хуя... Я, наверное, тупой, просто не увидел ответ на первой странице...
>>46431
Кажется начал понимать.
>DISTINCT'ы, посмотрел в dim_cash_register - там 23 записи, но касс всего 22 (кассы № 10 нет, а касса № 7 дублируется).
Кажется начал понимать.
>>46427
Да
You're getting this error because you're trying to add/update a row to table2 that does not have a valid value for the UserID field based on the values currently stored in table1. If you post some more code I can help you diagnose the specific cause.
Нет
Такое ощущение, что тебе лет 12, тебе никто ничего не должен.
Больше точека, петушок. Тебе об этом сказали почти сразу.
Ясн. А я то думаю, зачем вообще нужны ЯП с динамической типизацией, а оказывается Ваньки не могут в нормальные инструменты.
Ты даже его не в состоянии осилить юзай MongoBD.
Нет, тебе нужно сделать два коммита подряд.
> Об этом написано где-то было в том "ответе"?
Да
You're getting this error because you're trying to add/update a row to table2 that does not have a valid value for the UserID field based on the values currently stored in table1. If you post some more code I can help you diagnose the specific cause.
>я то был прав насчет видимости результатов запросов в контексте транзакции?
Нет
>Но вот только что-то никто не дополнил мою мысль, да? Еее для вас как буд-то и не было.
Такое ощущение, что тебе лет 12, тебе никто ничего не должен.
>А теперь, выясняется, что виной-то всему был констрейнт)))))) Хех))) Но да ладно, опять же... Коммит... Знаешь? А я его делал...
Больше точека, петушок. Тебе об этом сказали почти сразу.
>для node js
Ясн. А я то думаю, зачем вообще нужны ЯП с динамической типизацией, а оказывается Ваньки не могут в нормальные инструменты.
>mysql
Ты даже его не в состоянии осилить юзай MongoBD.
>надо создавать savepoint
Нет, тебе нужно сделать два коммита подряд.
>>46438
Ну, читай внимательней.
Ну, читай внимательней.
>>46460
Лень отвечать на одно и тоже в десятый раз. Баран он и есть баран. На последнее только отвечу
Чтобы второй кусок в случае ошибки не записался, а первый остался болтаться в бд закоммиченный? Ебать, тут гении сидят...
Лень отвечать на одно и тоже в десятый раз. Баран он и есть баран. На последнее только отвечу
>тебе нужно сделать два коммита подряд.
Чтобы второй кусок в случае ошибки не записался, а первый остался болтаться в бд закоммиченный? Ебать, тут гении сидят...
>>46460
php? Подставляй рот к моему волосатому анусу, сейчас еду космонавтов будешь дегустировать.
>нормальные инструменты
php? Подставляй рот к моему волосатому анусу, сейчас еду космонавтов будешь дегустировать.
>>46458
Предположим у тебя соеденение
1------2-----3
В первой таблице например 21 запись, во второй 15, а в третьей опять 21, и поэтому без одностороннего жоина что-то проебывается. Посмотри таблицы, и поставь среднюю в конец с правым жоином.
Предположим у тебя соеденение
1------2-----3
В первой таблице например 21 запись, во второй 15, а в третьей опять 21, и поэтому без одностороннего жоина что-то проебывается. Посмотри таблицы, и поставь среднюю в конец с правым жоином.
>>46490
Поковырялся. По сути верный результат даёт и такой запрос:
SELECT ...
FROM dbo.fct_cheque AS f
INNER JOIN (SELECT DISTINCT * FROM dbo.dim_goods) AS g
ON G.good_id=f.good_id
WHERE ...
Поковырялся. По сути верный результат даёт и такой запрос:
SELECT ...
FROM dbo.fct_cheque AS f
INNER JOIN (SELECT DISTINCT * FROM dbo.dim_goods) AS g
ON G.good_id=f.good_id
WHERE ...
>>46548
Ну тебе ж ещё третья таблица нужнп
Ну тебе ж ещё третья таблица нужнп
С чем может быть связанна медленная проверка? индексы есть
есть запрос вида:
SELECT * FROM `somes` WHERE A=? AND B=?
A и B оба индексы, так вот, если я выполняю без AND B получаю примерно 0.002 секунды выполнения, если с B получаю 0.04 и это пиздец, с чем это может быть связанно?
судб: mariadb
есть запрос вида:
SELECT * FROM `somes` WHERE A=? AND B=?
A и B оба индексы, так вот, если я выполняю без AND B получаю примерно 0.002 секунды выполнения, если с B получаю 0.04 и это пиздец, с чем это может быть связанно?
судб: mariadb
>>47100
он сначало смотрит на записи по индексу А, потом для каждой из них проводит запрос, ищет совпадение с индексом B, таким образом из обычного if id == ? && govno == true мы получаем if id==? && govnos.contains(id)
он сначало смотрит на записи по индексу А, потом для каждой из них проводит запрос, ищет совпадение с индексом B, таким образом из обычного if id == ? && govno == true мы получаем if id==? && govnos.contains(id)
>>47117
это я сам придумал сам поверил, иначе как обьяснить тот пиздец я не ебу
там 3миллиона записей в таблице
это я сам придумал сам поверил, иначе как обьяснить тот пиздец я не ебу
там 3миллиона записей в таблице
>>47132
А - parent, соотвественно например у тысячи ячеек может быть одно и тоже значение в А
B - deleted, юзал число, так как бул не умеет в индексы
А - parent, соотвественно например у тысячи ячеек может быть одно и тоже значение в А
B - deleted, юзал число, так как бул не умеет в индексы
Так, уебища, которые вчера тут выебывались и гнали на меня. Что теперь скажете? Тебя тоже касается, уебок >>46460 конкретно это
Вот, аналогичная проблема. Абсолютно аналогичная. Только я вообще хз нахуя он это высрал, наверняка он работает из под своего шелла субд, а не как я через api пакета node js.
я то был прав насчет видимости результатов запросов в контексте транзакции?
https://stackoverflow.com/questions/20876291/sql-foreign-key-before-commit
Я, кстати и сам проверил это из под workbencha. Там все работает, а у меня после вставки в родительскую таблицу и вставки в дочернюю по внешнему ключу ошибка:
И идите на хуй со своими промежуточными коммитами, дегенераты ебучие. Жду ответов адекватных специалистов итт, а не ебаного свитерного скама. Но тут таких скорее всего нету...
>я то был прав насчет видимости результатов запросов в контексте транзакции?
>Нет
Вот, аналогичная проблема. Абсолютно аналогичная. Только я вообще хз нахуя он это высрал, наверняка он работает из под своего шелла субд, а не как я через api пакета node js.
я то был прав насчет видимости результатов запросов в контексте транзакции?
https://stackoverflow.com/questions/20876291/sql-foreign-key-before-commit
Я, кстати и сам проверил это из под workbencha. Там все работает, а у меня после вставки в родительскую таблицу и вставки в дочернюю по внешнему ключу ошибка:
>Cannot add or update a child row: a foreign key constraint fails ('solach'.'info_matches', CONSTRAINT 'info_matches_ibfk_1' FOREIGN KEY ('id_match') REFERENCES 'matches' ('id'))
И идите на хуй со своими промежуточными коммитами, дегенераты ебучие. Жду ответов адекватных специалистов итт, а не ебаного свитерного скама. Но тут таких скорее всего нету...
MS SQL
Есть одна БД с режимом совместимости = 100 (поскольку я не очень умный и спросить сейчас не у кого, то будем считать что лучше ему таким и оставаться, либо, что это значение будет изменено на неизвестное другое, которому так же лучше не менять).
У этой БД есть хранимая процедура, в теле которой очень хочется использовать STRING_SPLIT (который требует режим совместимости 130).
Собственно идея ночью чуть-чуть изменить гравитационное поле Земли в теле процедуры поменять режим совместимости на нужный, сделать STRING_SPLIT, а затем всё вернуть обратно.
Насколько это ебануто? Если не очень - то следом два вопроса
- Допускается что имя БД, может быть изменено, следовательно я использую вывод DB_NAME(), записанный в переменную @currentdb. Но ALTER DATABASE @currentdb ... работать не будет. Как быть?
- Касаемо ALTER DATABASE database_name SET COMPATIBILITY_LEVEL = оригинальное_значение
Можно ли каким-нибудь вместо оригинального значения использовать переменную?
Или стоит прикинуться веником и тупо менять используя актуальные значения имени БД и её уровня? Или вообще идея не ок и стоит думать дальше?
Есть одна БД с режимом совместимости = 100 (поскольку я не очень умный и спросить сейчас не у кого, то будем считать что лучше ему таким и оставаться, либо, что это значение будет изменено на неизвестное другое, которому так же лучше не менять).
У этой БД есть хранимая процедура, в теле которой очень хочется использовать STRING_SPLIT (который требует режим совместимости 130).
Собственно идея ночью чуть-чуть изменить гравитационное поле Земли в теле процедуры поменять режим совместимости на нужный, сделать STRING_SPLIT, а затем всё вернуть обратно.
Насколько это ебануто? Если не очень - то следом два вопроса
- Допускается что имя БД, может быть изменено, следовательно я использую вывод DB_NAME(), записанный в переменную @currentdb. Но ALTER DATABASE @currentdb ... работать не будет. Как быть?
- Касаемо ALTER DATABASE database_name SET COMPATIBILITY_LEVEL = оригинальное_значение
Можно ли каким-нибудь вместо оригинального значения использовать переменную?
Или стоит прикинуться веником и тупо менять используя актуальные значения имени БД и её уровня? Или вообще идея не ок и стоит думать дальше?
>>47219
Ну то есть ты только что.
>Жду ответов адекватных специалистов итт, а не ебаного свитерного скама
Ну то есть ты только что.
>>47256
Чел, я уже понял что ты только можешь срать под себя как старый дет итт, так что схлопни ебальничек, будь добр и залезь обратно под свой законный шконарь...
Чел, я уже понял что ты только можешь срать под себя как старый дет итт, так что схлопни ебальничек, будь добр и залезь обратно под свой законный шконарь...
Пиздец дохуя постов, а ни одной нормальной книги так и не посоветовали, специалисты хуевы
>>47308
Но я же кидал нормальные видеоуроки...
Но я же кидал нормальные видеоуроки...
>>47253
>>47337
Советую погуглить, что такое CLR в MS SQL, и накодить ту же самую функцию на шарпе, внедрив ее в составе сборки в SQL Server.
Самое полезное здесь то, что помимо пресловутой split_string ты можешь сделать на шарпе абсолютно все, чего SQL сервер не умеет из коробки. Например, нормальный парсер регулярок, исполнитель веб-вызовов и т.п.
>>47337
Советую погуглить, что такое CLR в MS SQL, и накодить ту же самую функцию на шарпе, внедрив ее в составе сборки в SQL Server.
Самое полезное здесь то, что помимо пресловутой split_string ты можешь сделать на шарпе абсолютно все, чего SQL сервер не умеет из коробки. Например, нормальный парсер регулярок, исполнитель веб-вызовов и т.п.
>>47253
Ну и для всяких alter database [...] с хз, каким названием до момента исполнения ты можешь юзать dynamic sql:
declare @sql nvarchar(4000) = 'ALTER DATABASE ' + @db_name + ' set ...';
exec (@sql);
Ну и для всяких alter database [...] с хз, каким названием до момента исполнения ты можешь юзать dynamic sql:
declare @sql nvarchar(4000) = 'ALTER DATABASE ' + @db_name + ' set ...';
exec (@sql);
>>47866
Ну раз ненужная, продоолжай ебаться с совместимостями, динамик скл, и ковырять строки через
Это же в 100 раз удобнее
Ну раз ненужная, продоолжай ебаться с совместимостями, динамик скл, и ковырять строки через
>charindex(charindex(charindex(charindex(charindex
Это же в 100 раз удобнее
>>48013
Языки NoSQL бд.
Языки NoSQL бд.
Насколько падает перформанс, если у меня запрос вида select from select?
Сначала выбираю ВСЮ таблицу (уже хуево звучит), а затем из нее некоторые записи.
Дело в том, что мне надо подсчитать ранк записи (номер по порядку) у каждого юзера среди ВСЕХ его записей, но выбирать надо лишь некоторые конкретные записи, а не все.
Сначала выбираю ВСЮ таблицу (уже хуево звучит), а затем из нее некоторые записи.
Дело в том, что мне надо подсчитать ранк записи (номер по порядку) у каждого юзера среди ВСЕХ его записей, но выбирать надо лишь некоторые конкретные записи, а не все.
>>48076
JOIN производительней.
JOIN производительней.
так, порни, выручайте, нужно получить данные с базы одной
на вход подаётся параметр zadachi, в котором указываются номера задач (например: "'4-1-1-1', '4-1-1-2'")
насколько я понял это значение тупо подставляется в where in()
никакой проверки вроде нет, но конструкции вида '4-1-1-1') OR 1=1 -- не срабатывают
на вход подаётся параметр zadachi, в котором указываются номера задач (например: "'4-1-1-1', '4-1-1-2'")
насколько я понял это значение тупо подставляется в where in()
никакой проверки вроде нет, но конструкции вида '4-1-1-1') OR 1=1 -- не срабатывают
>>48076
твой
select
from ( select ..., rank() over() as RNK from ...) t
where t.RNK = 1
не выбирает в подзаопросе всю таблицу, это нормальная практика в аналитических запросах, если тебе всех зеров обсчитать нужно.
С точки зрения оптимизации можно предложить такой вариант:
при загрузке данных в исходную табличку можно сразу
1. выбирать всех пользователей, по которым есть новые данные
2. Обсчитывать ранк для них и записывать его в таблицу
Таким обзразом в результате можно селектить уже без подзапроса.
твой
select
from ( select ..., rank() over() as RNK from ...) t
where t.RNK = 1
не выбирает в подзаопросе всю таблицу, это нормальная практика в аналитических запросах, если тебе всех зеров обсчитать нужно.
С точки зрения оптимизации можно предложить такой вариант:
при загрузке данных в исходную табличку можно сразу
1. выбирать всех пользователей, по которым есть новые данные
2. Обсчитывать ранк для них и записывать его в таблицу
Таким обзразом в результате можно селектить уже без подзапроса.
>>48121
что такое 4-1-1-1? текстовый код, по которому можно однозначно идентифицировать конкретную задачку?
что такое 4-1-1-1? текстовый код, по которому можно однозначно идентифицировать конкретную задачку?
>>48125
да, помимо этого можно сразу пачку задач получить просто указав число (например 4)
да, помимо этого можно сразу пачку задач получить просто указав число (например 4)
>>48130
А количество уровней воженности точно определено или нет?
Например, 4-1-1-1 - это конечный уровень или может быть
4-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1?
А количество уровней воженности точно определено или нет?
Например, 4-1-1-1 - это конечный уровень или может быть
4-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1?
>>48121
Помимо прочего, какая у тебя СУБД, параметр прилетает куда? У тебя приложение или только хранимая процедура и все?
Блжад, напиши полное описание задачи, ни хуя непнятно, ненавижу, когда 100 вопросов прихоится задавать, а потом автор еще и сливается, поняв, что волшебная пилюла в виде "вот сделай так" не существует и придется все подробно рассказать, чтобы получить решение.
Помимо прочего, какая у тебя СУБД, параметр прилетает куда? У тебя приложение или только хранимая процедура и все?
Блжад, напиши полное описание задачи, ни хуя непнятно, ненавижу, когда 100 вопросов прихоится задавать, а потом автор еще и сливается, поняв, что волшебная пилюла в виде "вот сделай так" не существует и придется все подробно рассказать, чтобы получить решение.
>>48150
конечный, номера задач хранятся в виде строк скдя по всему
конечный, номера задач хранятся в виде строк скдя по всему
>>48161
Допустим тебе такое прилетает:
["4", "5-1-1-1"]
параметр надо распарсить в приложении, поняв, какой из кодов конечный, а какой - нет. То есть 5-1-1-1 - кконечный, судя по иерархии.
Далее генерируем запрос, добавляя через OR коды задачек и вставляя их, используя разные условия сравнения в зависимости от того, конечный это уровень или нет. Если неконечный, то like 'КОД%', если конечный, то ='КОД':
select
*
from task t
where t.code like '4%'
or t.code = '5-1-1-1'
Допустим тебе такое прилетает:
["4", "5-1-1-1"]
параметр надо распарсить в приложении, поняв, какой из кодов конечный, а какой - нет. То есть 5-1-1-1 - кконечный, судя по иерархии.
Далее генерируем запрос, добавляя через OR коды задачек и вставляя их, используя разные условия сравнения в зависимости от того, конечный это уровень или нет. Если неконечный, то like 'КОД%', если конечный, то ='КОД':
select
*
from task t
where t.code like '4%'
or t.code = '5-1-1-1'
>>48217
ты не понял, мне нужно инъекцию произвести, кавычки вместе с запросом нужно отсылать, поэтому тип данных может быть любой
я пробовал выражения наподобие 2+2 ставить и всё работало, вот только как свой запрос вставить не пойму
ты не понял, мне нужно инъекцию произвести, кавычки вместе с запросом нужно отсылать, поэтому тип данных может быть любой
я пробовал выражения наподобие 2+2 ставить и всё работало, вот только как свой запрос вставить не пойму
>>48280
предположительно есть столбец с номером (например '4-1-1-1'),
с заданием, решением (шифровано в AES) и ключом для дешифровки
ключи мне выкачать удалось (не инъекцией), осталось сами решения получить
предположительно есть столбец с номером (например '4-1-1-1'),
с заданием, решением (шифровано в AES) и ключом для дешифровки
ключи мне выкачать удалось (не инъекцией), осталось сами решения получить
так, результат при использовании
4) # не измерился, а значит там какая-то проверка на комментарии была
4) # не измерился, а значит там какая-то проверка на комментарии была
>>47219
О, ебанная посредственность, ты все ещё тут? Два дня просидел ответа так и не нашел?
Ладно, для аутиста который не может в обучение, поясню:
Представь себе, что в рамках одного коммита ты вставляешь лям строк в родительскую таблицу и два ляма строк в дочернюю таблицу. (допустим, вставка у тебя занимает 3 минуты). Проходит 30 секунд, и аутист типо тебя твой брат, например вставляет в родительскую таблицу строчку, которая есть у тебя в ещё не закрытой транзакции, причем это первый инсерт в твоей транзакции. На какое значение должна ссылаться дочерняя таблица? На то, которое есть в ещё не закрытой транзакции или на уже закоммиченное значение, додик?
О, ебанная посредственность, ты все ещё тут? Два дня просидел ответа так и не нашел?
Ладно, для аутиста который не может в обучение, поясню:
Представь себе, что в рамках одного коммита ты вставляешь лям строк в родительскую таблицу и два ляма строк в дочернюю таблицу. (допустим, вставка у тебя занимает 3 минуты). Проходит 30 секунд, и аутист типо тебя твой брат, например вставляет в родительскую таблицу строчку, которая есть у тебя в ещё не закрытой транзакции, причем это первый инсерт в твоей транзакции. На какое значение должна ссылаться дочерняя таблица? На то, которое есть в ещё не закрытой транзакции или на уже закоммиченное значение, додик?
>>47219
Да пошёл ты на хуй. Научись сначала разговаривать нормально, обезьяна, заебал уже всех своими свитерами. Желаю тебе ни хуя ни в чем не разобраться, пока не исправишься и не извинишься перед анонами.
Не отвечайте этому дауну, он все треды уже своим говном засрал. Мало того, что тупой и какие-то элементарные вещи не понимает, так еще и ЧСВ себе отрастил, как будто ноые парадигмы хранения данных каждый день внедряет.
Да пошёл ты на хуй. Научись сначала разговаривать нормально, обезьяна, заебал уже всех своими свитерами. Желаю тебе ни хуя ни в чем не разобраться, пока не исправишься и не извинишься перед анонами.
Не отвечайте этому дауну, он все треды уже своим говном засрал. Мало того, что тупой и какие-то элементарные вещи не понимает, так еще и ЧСВ себе отрастил, как будто ноые парадигмы хранения данных каждый день внедряет.
С sql знаком немного, надеюсь поясните нубасы один момент. Вот есть у меня таблица произведений и у этих произведений есть какое-то разное произвольное кол-во глав и в каждой главе какой-то текст. Так вот как лучше такое хранение организовать? Я придумал только или создавать для каждого произведения отдельную таблицу с номером главы и значением, или сделать одну большую таблицу с внешним ключем id_произведения.
Ну и посоветуйте какой-то ресурс или книгу, где рассказываются разные паттерны проектирования бд.
Ну и посоветуйте какой-то ресурс или книгу, где рассказываются разные паттерны проектирования бд.
>>48490
Ну камон, блаженным помогать нужно.
Это жс петух обыкновенный, его пока еблом в говно не тыкнеш, он срать продолжит.
Ну камон, блаженным помогать нужно.
Это жс петух обыкновенный, его пока еблом в говно не тыкнеш, он срать продолжит.
>>48517
Почитай про нормальные формы.
Почитай про нормальные формы.
76 Кб, 1264x781Анон, вот такой вопрос: а нахуя при создании бд в монго указывать сразу название колекции? Что это за колекция и нахуя она нужна? Если не указать, создать не дает.
>>48762
Чё-т проиграл с того, что монга не дает создать говно.
Коллекция - мб что-то типа дефолтной схемы?
Чё-т проиграл с того, что монга не дает создать говно.
Коллекция - мб что-то типа дефолтной схемы?
>>49018
Не ебу, потому и спрашиваю. Вполне может быть, но если так, то нахуя оно надо?
Не ебу, потому и спрашиваю. Вполне может быть, но если так, то нахуя оно надо?
Использую sqlite, запускаю в бесконечном цикле в роутине некоторую проверку, то есть беру из бд ссылки и пингую их, обновляя статус доступен/недоступен. На моменте старта этой роутины у меня крашится программа. Это из-за блокировки в самой sqlite или я что-то не правильно накодил?
>>49418
в Sqlite есть event notifications:
https://www.sqlite.org/c3ref/update_hook.html
Так можно не грузить свою базу селектами, а просто подписаться на события, мне кажется, такой способ в 100 раз практичнее
в Sqlite есть event notifications:
https://www.sqlite.org/c3ref/update_hook.html
Так можно не грузить свою базу селектами, а просто подписаться на события, мне кажется, такой способ в 100 раз практичнее
Тред утонул или удален.
Это копия, сохраненная 31 января 2020 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 31 января 2020 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.