Comments 108
таблица партициирована (или как это правильно сказать по-русски?).
партиционирована?
партиционирована
партициирована
партицирована
секционирована
Вот так бывает читаешь русскую документацию, а там какая нибудь расчлененка. И понять не можешь, о чем говорит автор. И какой выход? В скобках указывать что именно имеется ввиду? А смысл тогда переводить.
Переводить термин можно, когда он уже имеет устойчивый аналог.
С другой стороны — а откуда им взяться этим «устойчивым аналогам» если их не насаждать с самого начала?
ИМХО переводить надо в самом начале, когда термин только появляется. Потом поздно уже. Бывало пару раз что бросал русский мануал (ладно, ладно, русскую документацию) и читал в оригинале, только потому что термины переведены и приходится мысленно переводить их обратно а то не понятно.
Упс, не туда опять.
Недавно. С 9.6 начали параллелиться несколько определённых операций в одном запросе, в 10-ке их количество увеличилось.
оптимизатор запросов вначале делает отбор для простых условий, а потом для сложных как для 1с?
Тут вам дорога к Postgres Professional — у них были специальные сборки для 1С (но 10-ки пока не видать): https://postgrespro.ru/products/1c
Уж лучше пусть 1С научится работать с PostgreSQL как он есть. И всем будет проще. И PostgreSQL можно будет ставить из официальных пакетов и дистрибутивов. Речь о пакетах для linux.
1с изначально не поддерживала работу с версионниками поэтому в постгресс всталяется костыль для поддержки.
+ меняется оптимизатор запросов для более эффективной работы с запросами 1с.
Переписывать всю платформу из за того, что кто то хочет чистый постгес не думаю что кто то будет.
Если ошибаюсь, пожалуйста поправьте.
Поэтому можно бесплатно поставить Linux Server+ Postgresql, а можно MS server+МSSQL. ПРАКТИЧЕСКИ во всех задачах, кроме 1с первая связка будет производительнее. Но для 1с, даже если вы не верите в теории заговора — вторя будет быстрее.
В стиле КО: для настройки и там и там нужны прямые руки.
Нет, ну серьезно. Поиграйтесь их построителем запросов.
У них архитектура предметно-ориентированная, что имеет свое отражение во внутреннем языке запросов, который суть обычный sql-select со всеми join, unit и т.п., только переведенными на русский. Вот только при более глубоком взгляде — очень много технических деталей скрыто под капотом. Вроде и sql-запросы, но протечек абстракции там меньше. Регистры скрывают свою реализацию, просто логика. У таблиц (документы, справочники и т.п.) есть подтаблицы, т.е. по сути движок неявно добавляет join-ы там где это надо, а мы строим запрос исходя только из бизнес-логики.
Резюмируя — внешние ключи это конечно очень важно, но… не для одинэсника.
Я понимаю что мой комментарий будет явно непопулярным в данной теме, но не все люди пишут на ассемблере. Не все пишут sql-запросы. Я например оказавшись в голом окружении сразу пишу себе какой-то простенький ORM. Я не в восторге от всего что сделали 1С, но общее направление у них верное — как можно больше технических деталей скрыть от прикладного разработчика. Ему предметную область понимать… освободите его хоть от технических подробностей).
Во первых вы явно не сталкивались с глюками транслятора всей этой билеберды в SQL. Было дело мы полгода ждали лечения бага join. Кроме того уж незнаю что они там вытворяют но у меня есть отчетик который на sql выполняется секунду, а в 1с 25 минут. Вы считаете это нормальным?
«не для одинэсника»: вот потому одинэсники пишут какие то дикие костыли там, где все прочие ставят внешний ключ и не мучаются. А уж какое веселье наступает когда есть несколько табличных частей ссылающихся друг на друга, уухх…
И уж простите, но их конструктор почти неюзабелен на более менее крупных запросах.
ЗЫ у меня вообще есть подозрение что 1с более менее работает в крупных компаниях только за счет покрывающих индексов MsSQL
ЗЫЗЫ по поводу перевода на русский: я незнаю как вам но мне особую боль доставляет вспоминать «объединить» это join или union.
Философия «каждая кухарка может программировать 1с» у них лежит в основе, но она себя не оправдала.
Еще как оправдала. Покажите мне конкурента у которого другая философия и такой же масштаб клиентской базы (разумеется в их нише). Каждая кухарка здесь не в контексте просто низкого порога вхождения (по аналогии с киллерфичей пхп), а скорее по аналогии с Keyword Driven Testing и прочими подходами когда эксперта в предметной области ставят как можно ближе к коду.
Во первых вы явно не сталкивались с глюками транслятора всей этой билеберды в SQL.
Не сталкивался, признаюсь. Единственный мой опыт с 1с это поддержка РИБ на 65 удаленных узлов с обменом по фтп, файловым и некоторым самопальным гибридом из файлового и фтп с использованием пхп (да, это была конфигурация «Управление НазваниеОрганаВласти 8.0» и была закрытая, с обменом с базой в главке, а я поддерживал только областную структуру). База была адовая, сделана задней левой. «Разработчик» ориентировался изначально на аналогичную структуру в другой области, но там вообще несоизмеримые масштабы. Я к ним ездил по обмену опытом. Их начальник собирал на совещание всех инспекторов в одном кабинете. А у нас все начальники отделов в актовом зале не помещались. Ну и половины техпроцессов у них не было. Но хочу Вам сказать что хоть я лично и пострадал от «кухарки», но это нисколичко не аргумент против самого концепта. У того же 1с есть не только рядовые «специалисты» (или профессионалы? давно это было), у них есть уровни сертификации для разработки сложных проектов и там вполне вменяемый пипл тусуется. В моем случае это чисто проблема откатинга а не самого 1с. (Ну и конечно же в нашем случае 1с даром не сдался, он мало что решал из задач, зато лицензии таскать на каждое рабочее место..).
Я еще раз сделаю акцент — я не защищаю их реализацию, у меня у самого к ней много вопросов. Я просто поддерживаю их идеологию.
Кроме того уж незнаю что они там вытворяют но у меня есть отчетик который на sql выполняется секунду, а в 1с 25 минут. Вы считаете это нормальным?
Неа. Ненормально. Отчетик сами писали или левый «специалист»? ИМХО большая проблема 1с в том что они в своей сертификации ограничивают франчей снизу, но забывают об ограничении сверху. У них есть требования по минимальной квалификации чтобы лезть под капот, и даже по сути продавать полноценные коробки, но вот ограничения «если ты криворукий нуб без особой бумажки, то даже не пытайся писать собственную конфу или существенно допиливать существующую а то договор расторгнем и штрафов навешаем» — у них нет. И от этого все беды (не все, но многие).
вот потому одинэсники пишут какие то дикие костыли там, где все прочие ставят внешний ключ и не мучаются.
Неверное сравнение. Правильно так: «вот поэтому одинэсники пишут какие-то костыли там, где все прочие говорят: эй, программист, почему ты такой бестолковый, мне нужно вот эту штучку сложить с вот этой штучкой и распечатать так как требуется в нормативке».
И уж простите, но их конструктор почти неюзабелен на более менее крупных запросах.
Мы точно об одном и том-же говорим? Возможно я уже путаю терминологию. Я говорю не о query-bilder или объектной форме запроса данных из их скриптов, а о GUI-интерфесе. Он очень удобный и простой, и его возможности уходят далеко за пределы того что способен мысленно объять человек которому нужен такой конструктор. Тем более Если конфигурация делалась руками а не ногами. Я в нем делал трехэтажные запросы без проблем (join над юнионами из join-ов, да, без этого было никак, конфигурация была уж слишком сильно «откатовая»). И переделывал их тоже довольно глубоко в нем. Например спокойно накинуть еще четвертый уровень вложенности с групповыми операциями).
Вообще у меня техпроцесс был примерно такой:
1) набросать общую структуру в построителе
2) дописать мелочи типа сложных условий и т.п. в редакторе запроса (можно и в построителе, но тут уж быстрее руками чем мышкой)
3) отладить и отдать эникейщикам
4) дальше по обстоятельствам, или тупо выгрузка в эксель с допилкой, или добавляли свои условия, сортировки, группировки, в конструкторе, или я потом собирал полноценную обработку с красивым выводом
ЗЫЗЫ по поводу перевода на русский: я незнаю как вам но мне особую боль доставляет вспоминать «объединить» это join или union.
Это мне как раз вообще без вазелина вошло. Равно как и их «Если… то ..» и прочее. Буквально недели две на перестройку ушло. Мучения доставляло когда пишешь одновременно и на 1с и на чем-то нормальном, и помногу — были проблемы с клавиатурными автоматизмами, например знаки препинания разные и т.п.
Кстати а разве в запросах нельзя писать по нормальному? Насколько я помню скриптовый язык у них можно что анлийские ключевые слова использовать что русские, но не пробовал и не уверен что это касается запросов.
Еще как оправдала. Покажите мне конкурента у которого другая философия и такой же масштаб клиентской базы (разумеется в их нише). Каждая кухарка здесь не в контексте просто низкого порога вхождения (по аналогии с киллерфичей пхп), а скорее по аналогии с Keyword Driven Testing и прочими подходами когда эксперта в предметной области ставят как можно ближе к коду.
Исторически им уж так повезло. Хоть от 1с я не в восторге но их конкуренты еще хуже.
Неа. Ненормально. Отчетик сами писали или левый «специалист»? ИМХО большая проблема 1с в том что они в своей сертификации ограничивают франчей снизу, но забывают об ограничении сверху. У них есть требования по минимальной квалификации чтобы лезть под капот, и даже по сути продавать полноценные коробки, но вот ограничения «если ты криворукий нуб без особой бумажки, то даже не пытайся писать собственную конфу или существенно допиливать существующую а то договор расторгнем и штрафов навешаем» — у них нет. И от этого все беды (не все, но многие).
Отчет писал Специалист с большой буквы. Я проверял что он сделал.
Мы точно об одном и том-же говорим?
Об одном, но вы говорите об относительно простых вещах. У нас на 1с написана хитрая софтина учета с кучей табличных частей и вот по ней отчеты ну просто запредельно веселые.
В общем и целом я специализируюсь на разных утилитах оперирующих данными 1с при этом саму 1с никак не трогающих. Web-отчетики всякие хитрые, реестры платежей и прочее и прочее. И от того как 1с использует бд у меня волосы на голове шевелятся. Пусти начинающего php кодера к бд он и наверное умнее будет.
Исторически им уж так повезло. Хоть от 1с я не в восторге но их конкуренты еще хуже.
И майкрософт исторически повезло, и apple, и вордпрессу.
Клиентоориентированность и эргономика? Нет, лишь дело исторического случая.
Не поймите меня превратно. Яблоки скурвились, виндоус кривые а вордпресс — пережиток прошлого. Но в основе их успеха не случай или откаты, а исключительно удачные стратегические решения по основным принципам и подходам. К 1с у меня тоже много претензий, но сходу я их внятно не опишу. Но все эти компании для своего времени делали отличные решения и выбирали именно то, что было нужно рынку в то время.
Об одном, но вы говорите об относительно простых вещах. У нас на 1с написана хитрая софтина учета с кучей табличных частей и вот по ней отчеты ну просто запредельно веселые.
Это относительно простые вещи, но даже то о чем я говорю уже чрезмерно с точки зрения графического интерфейса для запросов.
Построитель нужен для создания запросов самим пользователем, ну и раз уж он у нас есть — может упрощать работу разработчику. А простому пользователю нафиг не нужны трехэтажные юнионы. Ему нужно чтобы разработчик изначально не косячил когда делал нормализацию структуры базы и можно было делать запросы без таких наслоений.
Но все эти компании для своего времени делали отличные решения и выбирали именно то, что было нужно рынку в то время.
Да никто и не спорит что в свое время они сделали удачные вещи в удачное время. Но сейчас 1с жрет непозволительно много времени. Кроме того она полна совершенно идиотских решений за безумные деньги. Чтобы с ней работать в более-менее сложном случае нужно купить штук 5 конфигурация и то их универсальный кривой интерфейс ест ну очень много времени. Пример: если вы работаете с одеждой то вы поймаете на своем пути столько пней, столько веселья… Справедливости ради не они одни этим грешат. Я на презентациях всевозможных ERP прошу при мне завести для примера пуховик с сеткой размеров: как правило уходит 30-60 минут уходит на это дело и приходит понимание, что продукт совершенно неюзабелен в этом случае.
Ему нужно чтобы разработчик изначально не косячил когда делал нормализацию структуры базы и можно было делать запросы без таких наслоений.
А вот тут как раз проблемка, ибо работа с кучей связанных табличных частей сопряжена со строительством заводика по производству костылей.
Кроме того:
— На Null не проверить
— составные индексы по бд не сделать
— функциональные индексы не используются
— да собственно даже в бд ничего не сделать, ибо все изменения вносятся через drop table
Я понимаю, что нынче политика: купите еще сервер. Но у меня при слове 1с-кластер начинает глаз дергаться.
И причем так везде. У нас с маленькой бд через обработку «выгрузка на сайт» выгрузка идет минут 20, а напрямую 0.2 секунды.
Интерфейс кассы на одну запись расходует минуты 2, а веб морда моя 20 секунд итд
А так то да, 1с это как вордпресс).
можно ваш код в студию?
Столкнулись с тем, что поддержки нет вообще. Отвечают по пол года в стиле «ничем не можем помочь, даже за деньги». Вызвали «крутого специалиста» из другой страны, которого рекомендуют сами интербейзы. Он посмотрел, сказал что «а фиг его знает почему оно ломается». У него есть какие-то приоритеты в тикетах разработчиков интербейза, но второй год результата ноль.
Теперь факты — проблемы не решены. Поддержка молчит. Спасаемся сложной системой бакапов-восстановлений каждые 15 минут. И срочно переписываем легаси. Я такого беспредела как поддержка «энтерпраиз уровня» базы не видел нигде и никогда за достаточно богатую айти жизнь. В один прекрасный день база просто перестает отвечать, не восстанавливается. Информации «что, собственно случилось-то?» — нет… Логи более чем бесполезны. Думайте сами стоит ли связываться, но если кто-то сейчас решает «а не выбрать ли мне интербейз для чего-то серьёзного» — полистайте гугль на предмет какие там бывают проблемы, посмотрите на даты этих самых проблем.
Просто личный опыт, ничего личного. Наболело. Если этот комментарий кто-то прочитает и задумается — возможно я только что спас людей от ранней седины.
Пакеты для линукс прекрасно ставятся из репозиторирия postgrespro — за что им низкий поклон. Вот бы ещё наконец для линукс дистрибутивов 1с сделали репозиторий. PeterG есть хоть какая то надежда? А то как то репозиторий для себя одного лениво становится поддерживать. А открыть доступ нельзя — атата за распространение.
а какой прирост производительности дают внешние ключи или это фишка нужная для языков неинтегрированных с БД?
2. 1с по лицензионному соглашению запрещает лезть ручками в базу если работает параллельно 1с. Особенности грязного чтения.
В общем вы правы. Смысла во внешних ключах нет.
А on update cascade для суроогатных первичных ключей и их внешних ключей вообще не нужен, на они и ключи, и суррогатные.
P.S. Холивар на предмет составных естественных ключей, которым оно иногда може и бывает нужно, я здесь разжигать не хочу.
Или филирование! ;)
Во всех профильных книгах секционированию посвящают хотя бы маленькую главу.
Тогда добавим немного пресмыкающихся: СРЕЗ. Собственно, оно так и есть, и даже вроде как логика аналогичная питону. Дай мне таблицу и я тебе срежу искомый кусок.
И опять про postgrespro https://github.com/postgrespro/postgres_cluster
Со слов Олега Сергеевича, если ничего не путаю, в их коммерческой версии есть и мультимастер для продуктива.
Ну понятно, что нормального мультимастера пока нет и раньше 12-13 версии pg его ждать глупо. По поводу костыльной реализации мультимастера на базе логической репликации здесь и сейчас… можете попробовать на двух серверах создать родительскую таблицу с двумя партициями. Ключом партицирования будет id сервера. На первом сервере при вставке в родительскую таблицу данные попадут в первую партицию, на втором сервере — во вторую. Первая партиция на втором сервере будет подписана на первую партицию на первом сервере. Вторая партиция на первом сервере будет подписана на вторую на втором. По факту такая конструкция может пережить сплит брейн за счёт того, что данные вносятся на каждом сервере в свою партицию и уникальность им обеспечит id сервера (поэтому конфликтов не возникает). Ну и делать такие вещи есть смысл не через нативное партицирование десятки, а через pathman. Но это так, теория, подобные костыли я не проверял.
И как всегда основной вопрос — как перевести термин, а можно ли вообще пользоваться новым механизмом партиций, учитывая его ограничения.
Это админы учат?
Там огромное количество самых простеньких на вид запросов, пока не наткнетесь на один, который вылетает с ошибкой. Ну и как пройдетесь по цепчке сопровождения дефектов, чтобы понять «почему», считай 50% науки освоили. Потом за каждые оставшиеся 10 придется уже платить сединой. А за последние 10 воюют все профессионалы.
Ну а там и до репликации доберётесь, если не сами, то если заказчик на проэкте потребует.
Сильной стороной Постгресса была и остается MVCC.
В конечном итоге, сегодня все производители СУБД вынуждены признать превосходство этой модели и внедрить её поддержку, некоторые после десятков лет вращения пятой точкой.
Слабым местом была и остается файловая система и регулятор потоков, основанный на мало — экономичной модели Юникса. Хотя появился новый класс задач, для которого сейчас любят, в рекламных целях, использовать слово «облако», эконмичность управления потоками для которого, по крайней мере на сегодня, не существенна, а вот возожность эффективного управления распределением запросов, и гибкость этого управлеия, главное.
Т. е. процесс внедрения ПО с открытым кодом сегодня находится перед развилкой, где одна команда людей, не боящихся писать на Си системный код может произвести скачек в области восприятия Постгресса.
Первое и самое яркое впечатление — все запросы отвечают с бешенной скоростью. Как человек с богатым опытом, скорость ответа заметна невооруженным глазом и первый индикатор класса базы.
Второе, все утилиты работают безупречно. Рабочий стол — конфетка, вылизан дочиста, писать запросы удовольствие. Сравнивая с десятком рабочих столов, от самых дорогих до SQL Workbench My SQL, собранного из исходников GitHub с кастом тулсами собственной добавки, этот самый легкий в общении и никогда не вываливается, от слова «вообще».
Если делаю ошибки, система отвечает внятными оповещениями. Процесс базы, сервис, выполняется уже несколько месяцев без нареканий. Запуск сервиса происходит молниеносно.
Отличная документация, отполированная и по содержанию и по презентации. В каждой детали изделия чувствуется класс разработчика.
Пожалуй самым трудным было добраться до странички чтобы скачать копию. У меня не очень цепкий взгляд и заняло какое — то время оглядеться на узле Релэкс. Но дальше все гладко.
Такие вот впечатления.
С Вашего разрешения сегодня позднова — то, посмотрю реализацию управления запросами и отвечу завтра.
Боги…
Так же обратил внимание на возможность выбора степени предвосхищения конфликтов параллельных потоков при соединении.Можно выбрать между пессимистичным, оптимистичнм и авто — транзакционным подходом управляющего потоками.
В общем то это надо ещё проанализировать, но складывается впечатление, что эти опии позволяют выбирать между, если не MVCC, то «мягким», «жестки» и по возможности взаимонезависимым распределением структур занятых защитой целостности данных в потоке на уровне клиента. Своеобразный подход, который больше нигде не видел. И потому не обратил внимание.
Раздел «Многоверсионная модель данных»
— Начиная с версии 6.1, СУБД ЛИНТЕР поддерживает многоверсионную модель данных.
— Реализация на уровне архитектуры позволяет обращаться к ядру СУБД Линтер в канале соединения по выбору с многоверсионной моделью данных, либо моделью доступа с блокировками. В свою очередь, многоверсионая модель доступа к данным предлагает выбор между блокирующей ( pessimistic ) и не блокирующей ( optimistic ) моделями доступа к данным конкурирующих запросов.
( Материал из Википедии — свободной энциклопедии )
PTC: Публичная компания, Листинг на бирже NASDAQ: PTC
Основание: май 1985, 31 год назад
Прежние названия: Parametric Technology Corporation
Основатели: Самуэл Гейсберг, Майк Пейн
Расположение: Нидем, Массачусетс, Соединённые Штаты Америки
Ключевые фигуры: Дональд К. Гриерсон (председатель совета директоров), Джеймс Хеппельманн (президент, генеральный директор) [1]
Отрасль: CAD/CAM/CAE/ PLM Software/ ALM/ SLM/ IOT
Продукция:PTC Creo, PTC Windchill, PTC Mathcad, PTC Integrity, PTC Servigistics, [1], [2]
Операционная прибыль: ▼ 41,6 млн долларов (2015)[2]
Чистая прибыль: ▼ 48 млн долларов (2015)[2]
Число сотрудников: 5982 (2016)[2]
Дочерние компании: PTC (Canada)[d]
Сайт: ptc.ru.com
PTC, Inc (прежнее название Parametric Technology Corporation)
ru.wikipedia.org/wiki/PTC_(%D0%BF%D1%80%D0%BE%D0%B8%D0%B7%D0%B2%D0%BE%D0%B4%D0%B8%D1%82%D0%B5%D0%BB%D1%8C_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8F)
2009 — Приобретение Relex Software с целью получения инженерного ПО для расчета надежности.[13]
То есть на сегодня Линтер это один из отделов частного предприятия полной ответственности, который рекламирует производство интеллектуальной матчасти для Министерства Обороны Российской Федерации ( пакет Линтер Бастион ).
Ну дела. А я тут понимаете ли, учу «отечественное программное обеспечение».
Интересно, насколько вероятно что "логическая репликация" сможет сходу заменить skytools… :)
www.postgresql.org/docs/10/static/sql-createpublication.html
На самом деле теперь нумерация стала ближе к SemVer, а главное — логичней. Старая нумерация: MAJOR1.MAJOR2.PATCH, новая — MAJOR.PATCH. Т.е. 9.6 — это был мажорный релиз после 9.5, несовместимый с ним по формату внутренней структуры файлов БД. Минорных релизов в понимании SemVer у PostgreSQL попросту нет. Цифру MAJOR1 скорее меняли по каким-нибудь праздникам, нежели из соображений обратной совместимости — логика там вроде бы и есть, но она не очень очевидная (так, 9.1 от 9.0 отличалась едва ли не сильнее, чем 9.0 от 8.4, хотя я тогда только начинал работать с постгре и помню плохо). Обратную совместимость поддерживают очень далеко в прошлое (приложению написанному под 8.4 вроде можно и сейчас подсунуть свежий постгрес и всё будет ок).
postgrespro.ru/docs/postgresql/10
Вышел PostgreSQL 10