Программирование, т. 8

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

Можно вечно смотреть на три вещи:
1. Едущий гироборд
2. Готовящийся смузи
3. Как фронтендер алгоритм быстрой сортировки пытается объяснить

fixed

ну транкейт взяли просто из-за скорости

данные нахер не нужны старые, а удаление всей таблицы не транкейтом это медленно, когда строк много

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

или даже больше, я даже не знаю точно, не я делал

так бля ёпта тут у нас транкейт блочит, хуё-моё, блядь, но если вторая транзакция обновляет, то блокировка становится... таак, падажжи ебана

чёт я запутался. транкейт это часть транзакции или это и есть целая транзакция?

почему транкейт или делит так долго? 3млн записей вроде не так много чтоб удаление шло 2 минуты, или оно лазит куда-то по всем ключам?

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

у тебя падажжи с моего текста, где уже всё описано, а у меня не было нихуя почти omegalul

транкейт внутри 1 транзакции, которая и пишет потом

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

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

2 транзакция вообще и не нашла бы ничего в таблице 1, но она обязана при апдейте сходить по всем ключам таблицы 2, один из которых светит на таблицу 1, а она даже дойти до таблицы 1 не может, тк sch-m говорит что нельзя вообще никак обращаться к таблице, нельзя верить даже названию и списку столбцов, и в итоге соси писос, пока "схема не закончит меняться"

1. отдельная транзакция на транкейт

2. как ты и предлогал - убрать fk с временной таблицы ибо они там нахуй не нужны

^ плюсую по п2

но я в этом всём не понял одного

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

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

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

схуяли

связи не обязательно должны быть FK

Laravel

В чем сука еще может быть проблема, кроме fillable полей?

"SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails

$inventoryPreview->previewType()->dissociate();
$inventoryPreview->save();

previewType() - HasMany relation

Ошибка с foreign key   ну и судя по коду, что-то не так ты делаешь )
$inventoryPreview->previewType()->dissociate(); - эта строка достает по связи данные, к save() то какое это отношение имеет?)

Ошибка с foreign key   ну и судя по коду, что-то не так ты делаешь )

$inventoryPreview->previewType()->dissociate(); - эта строка достает по связи данные, к save() то какое это отношение имеет?)

А что я не так делаю?

После dissociate $inventoryPreview->previewType возвращает null. А на строке save() падает. По этому у меня  к нему претензии

When removing a belongsTo relationship, you may use the dissociate method. This method will set the relationship's foreign key to null:

$user->account()->dissociate();

$user->save();

Вот из доков пример такой же.

^ плюсую по п2

 

но я в этом всём не понял одного

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

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

так она уже  начала, как она отпустит

она часть работы сделала, на вторую часть придется подождать, но с другой стороны то, чего она ждет, ждет ее первую часть

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

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

 

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

схуяли

связи не обязательно должны быть FK

 

потому что если у тебя не стоит ключ, у тебя нет связи между таблицами

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

@@fessnik

пофиксил тем, что форейн ки должен быть nullable.

fyi

потому что если у тебя не стоит ключ, у тебя нет связи между таблицами

схуяли?

я не знаю, что еще можно ответить на этот вопрос

потому что?

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

внешние ключи и созданы для этого

я не знаю, что еще можно ответить на этот вопрос

 

потому что?

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

 

внешние ключи и созданы для этого

ну может быть что угодно - и че?

в переменной джаваскрипта тоже может быть что угодно или undefined

но тем не менее мы сейчас сидим на форуме и успешно общаемся

...

если ты сейчас дропнешь все свои FK - что-то в приложении перестанет работать разве?

(кроме вещей который реально внутри бд завязаны на FK, типа каскадных операций)

у тебя джойны перестанут работать? или селекты из бд?

ты говоришь про консистентность базы

но у тебя явно бд не в 6ой нормальной форме ...

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

@@fessnik

пофиксил тем, что форейн ки должен быть nullable.

fyi

Да, я не знал про метод dissociate  думал это еще одна связь)

ты рофлишь что ли?

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

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

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

ты рофлишь что ли?

 

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

 

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

 

 

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

1. это ты рофлишь чтоли. ты серьезно не понимаешь что можно без FK счастливо жить в большом количестве ситуаций?

2. я не понимаю почему отсутствие фк для тебя проблема. там лежит то что ты туда положил. в код ты в любом случае будешь смотреть чтобы понять что есть что.

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

я не совсем понимаю почему что-то должно быть гарантировано. и почему ты считаешь что твои гарантии чего то стоят... как пример - что если разработчики бд допустили баг, и в 0.0005% случаев ограничение по FK не отрабатывает. где твоя гарантия тогда?

4. так, а к чему нормальные формы имеют отношение?

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

Ой прав) Я проект с чуваком пилили, так вот он сделал базу mysql на движке MyISAM (MyIsam какрас не поддерживает fk, в отличии от InnoDb с которой я обычно работаю) . Ну и че пилил проект как обычно, в миграциях прописывали fk , делали связи и тд. Проект с перерывами полтора года делали и вот буквально два дня назад я случайно заметил, что почему-то моя утилита для работы с бд как-то не так показывает поле которое должно быть фк. Начал копать и увидел что движек myisam используется)

 

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

 

 

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

ормки 

ормки

раза с 3го понял, что это не слово "орки" с ошибкой пишите