Excel, SQL и легендарный барометр — решаем простую задачу разными способами

[indestructable]

Почему бы не составить полный INSERT INTO ... конкатенацией строк и значений в формуле Экселя?
Только не забыть экранировать одинарные кавычки в строках.
А потом протянуть его до низу.

[muxa_ru]

Вариант с конкатенацией хороший.

Но протягивать на 1000 строк это неудобно. Надоедает. Даже если снизу тянуть и то надоедает. Сперва до низу скроллить, потом доверху тянуть.

Я час больше чем на пару сотен строк стараюсь не протягивать и решать другими средствами.

[indestructable]

1. Вводим формулу в первую строку
2. Выбираем диапазон с клавиатуры (вводим D1:D1000 в поле ввода слева от поля ввода для формул)
3. Выбираем в меню Fill

[muxa_ru]

Отлично, спасибо.

Только в п.2 нужно не просто ввести, но и энтер нажать.

[Rastishka]

Зачем тянуть? Можно даблкликнуть на уголок, за который вы тяните — оно само скопируется до низа таблицы.
Не благодарите. =)

[muxa_ru]

Это в чём так?

У меня LibreOffice и в нём не получилось :(

[Rastishka]

MS Excel

[muxa_ru]

Круто.

[ls1]

LibreOffice5 — всё работает

[muxa_ru]

Да, Ваша правда.

Пытался делать так на столбце находящимся через один пустой от столбца с данными.

Проверил — он копирует до низа соседнего столбца слева. Не до конца самого короткого или самого длинного столбца на листе.

[Self_Perfection]

Кажется любая приличная база данных умеет загружать данные из csv напрямую

http://dev.mysql.com/doc/refman/5.7/en/load-data.html
https://www.sqlite.org/cli.html#csv_import

Кстати, в условии задачи не было специфицировано, что БД именно MySQL или его форк.

[muxa_ru]

MySQL это я на своём примере, как и PHP. И того и другого можно легко заменить на любой другой SQL или язык программирования.

А в условиях просто SQL и неизвестно поддерживает ли он импорт из CSV. Поэтому этот вариант просто не рассматривал.

[Source]

[^0-9,-] — мягко говоря, не самая удачная регулярка для данной задачи… строки типа "1-2-3", "1,2,3", etc. останутся как валидные

[muxa_ru]

Задача не в том что бы проверить достоверность или корректность вводимых данных, а в том что бы не дать пропихнуть среди этих данных SQL-код.

Просто потому что вариант некорректности данных не рассматривается в условиях задачи.
А вариант что данные небезопасны должен учитываться всегда, а то будет как в случае с Joomla и взломом через User-Agent — http://www.securitylab.ru/news/477643.php

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

Вот картинка в LO после работы регулярных выражений.

[Source]

Во Вы даёте! Такой длинный коммент в ответ написать, при этом не прочитав тот, на который отвечали )))
Я ж Вам примеры "чисел" привёл, которые Ваша проверка пропустит до уровня SQL.
Или это был велосипед для защиты от SQL-Injection? А то, что SQL на вставку не сработает, — это ok?

В любом случае, то, что Вы делаете, противоречит фразе "применил регулярные выражения для удаления всего кроме числовых значений". Т.к. ряд вариантов нечисловых значений останется нетронутым.

[muxa_ru]

А то, что SQL на вставку не сработает, — это ok?

Да, регулярка нужна не для исправления некорректных данных, а для безопасности.

Не срабатывание импорта по причине наличия смысловых ошибок в исходном файле — ответственность поставщика файла. Всё на что я имею право в данной ситуации — сообщить поставщику файла о том, что данные были импортированы некорректно.

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

[Alexeyslav]

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

[Dr_Wut]

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