d-stream

можно заглянуть в движки популярных форумов типа invision powerboard, phpbb и т.п.
там давно уже выстроилась "косоплечая" конструкция хранения html с тэгами bbcode в комментариях - чтобы при редактировании сообщения вернуть назад bbcode, а не чистый html

Типичнейший кейс: редактирование базовых цен, групп и т.п. прайса.
Притом инструмент работающего с таковым должен уметь работать не только с excel, но и с другими форматами. И обладать достаточной гибкостью. Причина проста: средний сервис/магазин зч оперирует миллионами номенклатурных единиц (кодами з/ч), оные коды и политика ценообразования зависят от поставщика - т.е. один шлёт в excel код детали - цена - категория скидки - мин партия - срок, другой выгружает остаток склада в виде код-наименование-кол-во-цена, третий валит tab delimited прайс в у.е. и так далее.
Ручками такое никто набивать-перебивать-сверять не будет. А поставщик, особенно эксклюзивный - пошлёт искать на рынке другого поставщика)
Ну и да... зачастую ещё одни и те же запчасти могут иметь несколько разное кодирование под разные рынки-регионы)

В итоге сидит чел, тащит из зоопарка присылаемого в excel (например через мастер импорта) данные, сводит их к более-менее единообразному тасуя колонки, пересчитывая ндс и валюты. И потом хотел бы не выверять csv глазами на предмет затесавшегося "Болт М5; резьба1,5 мм" на котором импорт csv упадёт хоть с comma delimiter, хоть с semicilon ))))))))

database file - это файл какой-то базы данных)
Осталось выяснить какой именно, ну чтобы не пытаться открывать это mp3 плеером)
Имеющий перспективу вариант: любым hex просмотрщиком смотреть так называемую сигнатуру файла (первые 3-5 байт) и по этой сигнатуре искать что же это за субд. Если это не что-то внутрихуавеевское - то есть шанс.

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

Впрочем я могу подкинуть и гибридные промышленные дорогие решения где есть и орландо и редис и файлы)

Для сисадминства стоит сделать акцент на активных инвентаризаторах. То есть программах, которые прошерстят сеть и покажут оборудование, которое уже можно "разложить" по кабинетам/отвественным. Бонусом - проактивная защита от подмен/хищений: поменял ушлый клерк в системном блоке диск - система сообщила об этом.

для затравки: Total Network Inventory, OCS и т.п.

Наверное вариант Dbase частично подпадет под такие критерии - типа плоские таблицы, подразумевающие relation - то бишь связи между таблицами, но по сути набор dbf-файлов (таблиц) способных существовать без схемы в виде "рассыпухи")

А вообще схема - это и есть отношения aka relation и поэтому реляционная БД в любом случае подразумевает схему, но можно их держать виртуально в голове, а не использовать механизмы БД для этого - получим реляционную БД без реляций)
Естественно последнее сродни обману таксиста - оплатить поездку, но не поехать)

например на .NET есть bogus преспокойно описываются требуемые сущности и их вариации и вперед - заливать в базу

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

Почти всегда можно вместо курсора использовать временную таблицу (локальную, глобальную, memory)

Это ноги растут из dbase, где удаление не было удалением как таковым?
В чем видится недостаток чистого delete средствами СУБД?

Посоветуйте что выбрать.

Выбирайте специалиста, который имеет опыт - он обоснует что надо и почем. Естественно небесплатно. Но это все в конечном итоге будет в разы дешевле самообразования в строительстве велосипедов для езды по граблям.

Например про MS SQL:
Обычно такое выносится в виде отдельных инструментов, как например SQL Server Import Wizard для скорее интерактивного или же bcp для пакетного. Ну и есть и внутри начиная от bulk и заканчивая Data Transformation Service. И само собой sqlcmd - прямо stdin/stdout/stderr по классике.

Остальные - умеют плюс-минус то же самое и чаще всего из коробки (разве что dts не все)

В чем вопрос-то?

Умножение -более затратная операция чем сложение. Но это совсем не повод использовать сложение вместо умножения. В общем перефразируя профессора Преображенского - не надо читать такие статьи.

Самая "конечная" точка - триггеры. То есть например в момент реально финализировавшейся транзакции. Но от триггера "прогнать наверх" это событие - сильно зависит от архитектуры взаимодействия. Если есть некая таблица в БД, реализующая очередь уведомлений - то тогда можно триггером добавлять в нее это самое событие изменения... ну а дальше когда-то это уведомление будет вынуто из очереди и отправлено.

Третий вариант: stored procedure[s]* - на входе получающая нужные данные для добавления/изменения, которая уже в рамках транзакции выполнить проверки-записи-вычисления... притом тогда "магию" подвязанных к профилю контактов (еще таблички уже не 1:1) можно спрятать там же... так же как уведомления о смене чувствительных данных, логгирования и еще чего-нибудь потенциально нужного... притом последнее - собственно не потребует ничего менять за пределами такой процедуры.

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

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

То есть для РФ +7 (900) 100-00-00 , +7 (8765) 22-99-99, + 7 (876-55) 5-25-25, а эти же номера для немца окажутся 007 900 1000000, 007 876 5229999, 007 876 5552525,

а для усть-урюпинска - могут быть как:

8 900 100-00-00, 8-2 22-99-99 и 5-25-25

хотя в базе - это будет 3+ поля

в принципе хранить имеет смысл как int, а для "хитростей" поиска по частичным маскам - просто держать вычисляемые поля, где номер кастится к [n]varchar

Вполне нормально, особенно для работы с БД.
А сущности в памяти (и на экране) тогда соответственно могут быть изменены/удалены(помечены)/добавлены, что позднее "разветвит" их поведение (в конечном итоге update / delete / insert)