где дата начала и дата окончания записи фиксируется?

Нигде, ты сам должен ее фиксировать)

вот сейчас просто опишу свою подзадачу. офигеете от ее неприятности.

create

заглянул туда, там столько лишних действий... кеш, алиасы, куча событий, вычисление menuindex, группы ресурсов, короче всё что можно. Как вариант прямо в папке с процессорами создать копию файла create.class.php, скажем mycreate.class.php и повырубать всё лишнее. Не зняю правда насколько это трудоёмко

700 строчек не так много

заглянул туда, там столько лишних действий... кеш, алиасы, куча событий, вычисление menuindex, группы ресурсов, короче всё что можно. Как вариант прямо в папке с процессорами создать копию файла create.class.php, скажем mycreate.class.php и повырубать всё лишнее. Не зняю правда насколько это трудоёмко

а за прямые запросы к базе данных меня не побьют в сообществе modx? вроде как концепция обязывает использовать только механизмы ядра, нет?

а за прямые запросы к базе данных меня не побьют в сообществе modx? вроде как концепция обязывает использовать только механизмы ядра, нет?

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

и вообще все средства хороши, если вариантов нет)

у меня такая проблема сейчас, что главная таблица есть. и есть таблица "фирмы". уникальное поле у фирмы - это ИНН. но так получилось, что среди фирм есть много дублей, у которых ИНН одинаковый. И мне надо в главной таблице оставить поле одно поле только со ссылкой на правильную фирму, а не на ее клоны. Вичистить базу, котороче. удалить лишние фирмы и оставить в основной таблице только id актуальной версии фирмы, а всех клонов грохнуть. но у этих клонов есть свои подчиненные таблицы с адресами телефонами. Нужно чтобы они перешли к правильной вресии фирмы. И это я думал запросами реализовать. циклами то легко. но 2 ляма записей!

вот эту кашу разгребаю сейчас. и знаю как сделать. просто из-за того что 2 МЛН записей очень долго происходит всё.

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

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

это при помощи php или при помощи sql данный совет?

sql

slect distinct inn

парни тут любят distinct

парни тут любят distinct

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

ну тяните, тут уж вам виднее

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

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

вот сейчас полуавтомат светит только.

ну только по инн легко получить все формальные реквизиты по API

Та же dadata

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

зачем вся эта херня не ясно... ну разве что счетов там нет

Та же dadata

можно но не все к сожалению. мы эти данные дергали при помощи платных api которые не предоставляет dadata

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

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

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

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

как-то так, но всё равно куча нюансов всплывает)

ато в одном клоне могут емейлы быть заполнены, в другой телефоны.

ну это повсеместно))

клиент любит кнопочку "чистка от дублей". нажал и всё стало идеально в один клик

ага, лучше бы он любил порядок в базе)

вот вот. нефиг с разных баз таскать инфу )

без предварительной обработки

можно но не все к сожалению. мы эти данные дергали при помощи платных api которые не предоставляет dadata

у дадаты есть платные апи.

у дадаты есть платные апи.

есть. они просто не всю информацию предоставляют которую мы купили уже в другом месте. по кредитам всяким.

ну тогда купите 100 китайских женщин, которые будут вручную чистить :)

больше никак

ну тогда купите 100 китайских женщин, которые будут вручную чистить :)

ну как бы прогерское решение есть. перебрать всю таблицу клонов и выделить для каждой только один главные. недостающие данные дописать в основную запись. и удалить клонов.

Ну вперед. Интересно, как "прогерское решение" решит, какой мейл валидный, если в одной записи будет vasya123@mail.ru, а во второй vasya123@yandex.ru

Ну вперед. Интересно, как "прогерское решение" решит, какой мейл валидный, если в одной записи будет vasya123@mail.ru, а во второй vasya123@yandex.ru

не. задача только объединить записи от клонов )

куда ты их объединишь, если у тебя 10 клонов заполненных?

куда ты их объединишь, если у тебя 10 клонов заполненных?

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

ну как бы прогерское решение есть. перебрать всю таблицу клонов и выделить для каждой только один главные. недостающие данные дописать в основную запись. и удалить клонов.

а можно ещё так, одна запись оригинальная, случайная, и поле завести, которое будет хранить всю инфу о клонах. Типа emails : список адресов клонов, phones, и т.д.

мне хотелось написать единый запрос чтобы он всё это объединил и подменил на основное. все средствами sql

данные на месте, если что их можно поднять

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

данные на месте, если что их можно поднять

А так чтобы удалились все записи не уникальные по полю, например, по inn, но так, чтоб их дочерние записи пеершли к главной записи выбранной по дате добавления, к примеру.

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

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

под один запрос может попасть что-то не то

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

я бы так не стал делать) обязательно с косяками пройдёт, потом сиди гадай

я бы так не стал делать) обязательно с косяками пройдёт, потом сиди гадай

вот проще всего на php пару циклов организовать с элементами запроса и формирования выборки. и тогда задача будет решена за ночь ) ну я так и сделаю.

но это считается грязно. когда запрос внутри цикла.

тоже бы не стал так делать))

один косяк и ночь впустую

один косяк и ночь впустую

я просто видел аналог sql там такие запросы на несколько страинц просто запросы.

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

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

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

👌 я тоже такой подход только использую обычно. но думал что я "пидор" за то что так делаю.

ну когда в результате одним махом что-то не то удалишь, заказчик как раз так и назовёт)))

он то узнает не сразу

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

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

ну да, я так и делаю обычно

по крайней мере ничего не пропадало, не перезатиралось и т.д.

ну да, я так и делаю обычно

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

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

А вот это ты зря написал 😁

Но вы общайтесь, а я спать 😉

бьюсь об заклад, что они просто понтуются) им пофиг на качество, запустил скрипт, а там трава не расти. Простой факт, если этот способ рабочий, то тогда если делать всё тоже самое но порциями, не должно быть каких-то косяков, но они почему-то всплывают. И это не зависит от тебя, там просто данные могут быть совсем косячные, скажем из 1000 значений только 5 которых ты вообще не мог ожидать

если бы косяков таких не было, я бы делал всё за раз

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

если бы косяков таких не было, я бы делал всё за раз

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

не помню ни одного безпроблемного импорта

никогда не прощу гадов, которые иногда вместо заполненного поля ИНН выдают 00000000001 и 00000001

А зачем ты вообще добавляешь поля с кривым ИНН?

А зачем ты вообще добавляешь поля с кривым ИНН?

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

не помню ни одного безпроблемного импорта

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

сверки чего?

сверки чего?

сверки по их дынным, которые от них пришли

по их данным инн 00000000001

Такого инн не существует