Как сделать ключом значение type вместо индекса массива?

ага)

не путай v2 и v3

не понял)

https://www.google.com/search?q=recaptcha v2 vs v3&source=lmns&bih=979&biw=1920&hl=ru&sa=X&ved=2ahUKEwj8jayH9sj4AhUHSxoKHSixBGoQ_AUoAHoECAEQAA

keyBy()

https://laravel.com/docs/9.x/collections#method-keyby

Замечательно отработало! спасибо!

Файлы всегда имею разный набор строки колонок. Но у всех есть колонки типа age, num, country. Которые нужно найти. Сейчас я это делаю регулярками. Потом кладу в БД каждое поле с привязкой к позиции (columninidex, rowindex).

По итогу надо:
— Строить статистику — сколько строк в загруженном файле имеют email (определен), country(определен), birthday(прошел или нет) и тд — сколько повторений для type = num (из другой таблицы)
— Записывать ячейки обратно в строк в нужной последовательности

такие ситуация помечаются как спорные и отводятся для ручного принятия решения. Т-е тип изменяется вручную

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

Ну если у тебя уже есть такая таблица то ок, но я увидел таблицу в которой много всякого

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

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

то что я показал — как бы таблица pivot — если так можно выразиться….меня она тоже смущает. Но как иначе и удобнее можно хранить ячейки строк

надо обдумать. А в json держать где?

А нельзя держать базу под нужды проекта? А не под нужды импорта? И спорные моменты вообще хранить отдельно

И когда обхожу файл — забиваю эту таблицу.
Тогда возникает вопрос — если age не прошел валидацию — например проверку на >18 — где хранить этот статус? Если в отдельной таблице то как привязаться к таблице описанной выше.

Это все отдельно

Я б в соседней таблице держал. Выборки по таблицам с тяжелыми колонками дольше работают
Можно в целом хоть файл просто сохранять и путь до него. Зависит от частоты доступа к исходным данным

а как сослались бы на колонку?

Импорт норм вписывается если есть такие требования в проекте

Да просто внешним ключом, чего выдумывать тут

Это если проект об импорте, а если он о другом то импорт это отдельная история. Это просто источник данных для проекта

Так человек уже описал требования, чем это не подходит?

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

Для проекта тебе из них надо только три

Так это они у него щас важные только эти, появятся новые колонки — чего делать со старыми данными, сказать заказчику: извините, но мы не храним загруженные файлы? =)

три чего?

Файлы храни, в бд не храни не нужное

Три типа данных

Чуток больше — около 10. В примере тут я описал 3.

Не важно эти 10 и есть важные данные проекта

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

Хранить как ссылку на файл импорта ,json со строкой из файла и причиной конфликта

Сейчас таблица выглядит так:
Вы предлагаете ее не использовать а серилизовать каждую строку файла csv в json?

я бы хотел услышать мнение не о разруливании конфликтов. А об дизайне в целом. Потому как вы изначально заметили что в БД пздц