Тоже поделюсь авторским каналом в телеге. Собирает классные, делает небольшими партиями всегда разные но все они суперские. Под заказ может и любую собрать из предыдущих опытов. Но попасть в текущую партию дешевле. https://t.me/holyswitch.
Так как на моей Клаве как и у вас есть энкодеры транспортировка громоздкая. Есть мысля сделать ассиметричный кейс бампер для переноски. Сам придумал такую модель. Теперь осталось реализовать задумку.
Спасибо за статью. Добавлю свои 5 копеек. На экзаменах пользовался такой системой медведей. На двойных листах из общей тетради были написаны ответы на билеты. Но как достать нужный сложенный лист? Все просто нумеровал их черточками а-ля бинарнач система. Снаружи сгиба. Короткие длинные линии. В сложенной стопе эти номера хорошо видны. Когда лист на столе развернут распознать черточки на ободке нереально. Так что вам надо помимо общей линии для сортировки добавить ещё нумерацию в виде штрих кодировки. Тут фантазия большая. А-ля очень длинная линия это римская X, короткая I, средняя V. Ободка 30см хватит для чтения) ну а если это толстые тетради то проще сразу клеить на обод штрихкод, кр код и тп.
Было видно глазами. Причём сперва только красное облако, потом уже начались зелёные но не такие яркие как на севере а бледные но в стороне. И после минут 5 начались белые пронизывающие все небо от края до края по краям красные и зелёные. Звёзд вообще перестало быть видно. Белые полосы показались самыми страшными, потому что они очень быстро перестраивались а занимая все небо это выглядело очень огромным. Когда видишь как меняется расположение полос и колец от края неба до края неба в считанные доли секунды просто пугает. Иногда эти белые полосы выстраивались в замкуьые кольца но очень вытянутой дугой. И чередовались с чёрным цветом который вырисовывал чёткие фигуры в центре. Эти бело серые полосы и их пляска длились максимум минут 5.а вот красные облака спускающиеся с неба и зелёные обводы на одной из сторон света длились минут 30 ещё, больше глаз их не улавливал. Было ощущение что попал в самый эпицентр. Так как все представление было от центра в сторону небосвода. Было все очень хорошо видно при работе уличных фонарей но в частном секторе. Город Мамадыш.
поделюсь реальным кейсом когда этот тип хорошо выручил,
задача: не меняя записи в справочнике МКБ 10, так как он может в любой момент обновится из вне, в выборке отчета показать все записи с A00 по A09 кроме A04, объеденить в один список с болезнями Z29 select * from mkb10_tab2 d where d_ltr @ 'A0*&!A04|Z29'::ltxtquery
при этом план запроса: Bitmap Heap Scan on mkb10_tab2 d (cost=4.30..15.86 rows=3 width=348) Recheck Cond: (d_ltr @ 'A0* & !A04 | Z29'::ltxtquery) -> Bitmap Index Scan on ltree_ltr_ix (cost=0.00..4.30 rows=3 width=0) Index Cond: (d_ltr @ 'A0* & !A04 | Z29'::ltxtquery)
объяснить аналитику что такое A0*&!A04|Z29 гораздо проще чем куча AND OR в условиях WHERE без вдования в подробности в названия колонок при этом мы как раз такие условия отбора как A0*&!A04|Z29 хранили в отдельной таблице настройке. и для каждого отчета могли быть свои условия.
непривычно видеть первые ИД которые ссылаются на ИД которых еще не существует. вы просто смогли запутать целостность системы из 4х записей до такого состояния, что в итоге и не поймешь, что же можно удалять или апдейтить)
Под миграциями sql скриптами подразумевается create alter or drop объектов? А есть возможность накатывает в режиме compare и определять разницу между целевой и накатываемой структурой?
Работал в одной конторе, там новый начальник укомплектовывал свое окружение, набирал новый персонал
пришел студент 4го курса, участник и призер олимпиад по питону, показал свои проекты, мы все поняли что этот студент умнее начальника, но увы, его отбрили. Начальник в итоге нашел до чего докопаться: студент все делал на питоне 2,7 и до 3й версии еще не добрался. Завалили его вопросами чем отличается 3я от 2.7. Хотя в этой организации на это время тоже использовалась 2.7, так вот.
просьба еще explain (analyze, buffers) показывать,
и что если вместо
Представление «пути» в виде массива помогает во многих случаях
использовать для этой цели тип данных ltree.
может это жесткач будет но что если зная что у нас не может быть level больше 6, предварительно сделать таблицу(матвьюху) со всеми вариантами полученных «путей» для каждого узла в формате ltree + gin индекс на это поле
и тогда все запросы сведутся к поиску веток по индексу, а выше разобранный запрос использовать для заполнения ltree-)
на удаление БД надо иметь на это еще разрешение, второй момент, вы не можете удалить данную БД если в ней находитесь, надо подключаться к другой БД
в общем не все однозначно)
Заказать печать кейкапов можно? Как раз такой формат интересует.
Тоже поделюсь авторским каналом в телеге. Собирает классные, делает небольшими партиями всегда разные но все они суперские. Под заказ может и любую собрать из предыдущих опытов. Но попасть в текущую партию дешевле. https://t.me/holyswitch.
Текущая партия беспроводная.
Так как на моей Клаве как и у вас есть энкодеры транспортировка громоздкая. Есть мысля сделать ассиметричный кейс бампер для переноски. Сам придумал такую модель. Теперь осталось реализовать задумку.
Спасибо за статью. Добавлю свои 5 копеек. На экзаменах пользовался такой системой медведей. На двойных листах из общей тетради были написаны ответы на билеты. Но как достать нужный сложенный лист? Все просто нумеровал их черточками а-ля бинарнач система. Снаружи сгиба. Короткие длинные линии. В сложенной стопе эти номера хорошо видны. Когда лист на столе развернут распознать черточки на ободке нереально. Так что вам надо помимо общей линии для сортировки добавить ещё нумерацию в виде штрих кодировки. Тут фантазия большая. А-ля очень длинная линия это римская X, короткая I, средняя V. Ободка 30см хватит для чтения) ну а если это толстые тетради то проще сразу клеить на обод штрихкод, кр код и тп.
Помню раньше ржд билеты были все по московскому времени. Может быть это единственное место где можно было использовать without time zone.
Было видно глазами. Причём сперва только красное облако, потом уже начались зелёные но не такие яркие как на севере а бледные но в стороне. И после минут 5 начались белые пронизывающие все небо от края до края по краям красные и зелёные. Звёзд вообще перестало быть видно. Белые полосы показались самыми страшными, потому что они очень быстро перестраивались а занимая все небо это выглядело очень огромным. Когда видишь как меняется расположение полос и колец от края неба до края неба в считанные доли секунды просто пугает. Иногда эти белые полосы выстраивались в замкуьые кольца но очень вытянутой дугой. И чередовались с чёрным цветом который вырисовывал чёткие фигуры в центре. Эти бело серые полосы и их пляска длились максимум минут 5.а вот красные облака спускающиеся с неба и зелёные обводы на одной из сторон света длились минут 30 ещё, больше глаз их не улавливал. Было ощущение что попал в самый эпицентр. Так как все представление было от центра в сторону небосвода. Было все очень хорошо видно при работе уличных фонарей но в частном секторе. Город Мамадыш.
В сравнении и оптимизации ни одного explain не приложено. Это как сравнить тёплое с мягким получается.
поделюсь реальным кейсом когда этот тип хорошо выручил,
задача:
не меняя записи в справочнике МКБ 10, так как он может в любой момент обновится из вне,
в выборке отчета показать все записи с A00 по A09 кроме A04, объеденить в один список с болезнями Z29
select * from mkb10_tab2 d where d_ltr @ 'A0*&!A04|Z29'::ltxtquery
при этом план запроса:
Bitmap Heap Scan on mkb10_tab2 d (cost=4.30..15.86 rows=3 width=348)
Recheck Cond: (d_ltr @ 'A0* & !A04 | Z29'::ltxtquery)
-> Bitmap Index Scan on ltree_ltr_ix (cost=0.00..4.30 rows=3 width=0)
Index Cond: (d_ltr @ 'A0* & !A04 | Z29'::ltxtquery)
объяснить аналитику что такое A0*&!A04|Z29 гораздо проще чем куча AND OR в условиях WHERE без вдования в подробности в названия колонок
при этом мы как раз такие условия отбора как A0*&!A04|Z29 хранили в отдельной таблице настройке. и для каждого отчета могли быть свои условия.
непривычно видеть первые ИД которые ссылаются на ИД которых еще не существует.
вы просто смогли запутать целостность системы из 4х записей до такого состояния, что в итоге и не поймешь, что же можно удалять или апдейтить)
Под миграциями sql скриптами подразумевается create alter or drop объектов? А есть возможность накатывает в режиме compare и определять разницу между целевой и накатываемой структурой?
пришел студент 4го курса, участник и призер олимпиад по питону, показал свои проекты, мы все поняли что этот студент умнее начальника, но увы, его отбрили. Начальник в итоге нашел до чего докопаться: студент все делал на питоне 2,7 и до 3й версии еще не добрался. Завалили его вопросами чем отличается 3я от 2.7. Хотя в этой организации на это время тоже использовалась 2.7, так вот.
у меня кроме datagrip еще периодично notepad++ открывается
потом такие инструменты: https://explain.depesz.com/ парсер аналайза
http://json.parser.online.fr/ онлайн парсер json
и что если вместо
использовать для этой цели тип данных ltree.
может это жесткач будет но что если зная что у нас не может быть level больше 6, предварительно сделать таблицу(матвьюху) со всеми вариантами полученных «путей» для каждого узла в формате ltree + gin индекс на это поле
и тогда все запросы сведутся к поиску веток по индексу, а выше разобранный запрос использовать для заполнения ltree-)