ОК>>Ты сам честно ответь: видел ты такое за свою работу программистом? Я, вот, ни разу не видел чтобы кто-то разбивал название функции как это сделал он в своем примере.
W>Имена таблиц с префиксами/суффиксами видел?
Я уже ответил на этот вопрос. Видел. В коде поэтому ты ищешь фиксированную часть таблицы.
W>А функция в данном случае это обертка для таблицы или нескольких.
Неважно. В коде ты ищешь имя/идентификатор.
Ты разницу видишь между
string tableName = "my_big_table_" + year; // Это имя найти без проблем
и
string tableName = "just_big_" + "table"; // А это имя ты уже не найдешь
?
Последнее это что заявил ТС. Согласно нему, у него такое сплошь и рядом. Я выразил сомнение.
Здравствуйте, Олег К., Вы писали:
ОК>Какая фантазия? ТС нафантазировал уже. Поэтому я его и спросил о реальных случаях. Теперь ты мне снова предлагаешь проявить фантазию! И я тебя снова спрошу. Ты в реальном коде встречал такое или фантазируешь опять тут только?
Я объясню ещё раз: я работал в проекте где чистого SQL было 250MB исходников. Только люди которые имели опыта 10+ лет там разбирались. Все остальные, в том числе и я — фантазировали себе не весть что. С течением времени — это исправляется. У нас было до поры до времени весьма строгое оформление исходников, тем не менее — приходилось встречаться с уже описанными вещами. Поэтому мои фантазии — местами преувеличены — но осонованы на реальных историях.
Суть сводится приблизительно к одному: на определенном этапе — реально понимают что-то 2-3 человека, которые заняты и спросить вы у них сможете только на перекурах, и то только если вы курите. Так что как-бы "досвидания".
ОК>А так, нафантазировать и я могу. Радикальный пример я привел выше и повторю его специально для тебя:
Такого бреда нет наверное нигде. Но это не отменяет бредово отформатированный код, в котором внезапно таблицы с именами склеиваются посередине. Что, ограничение в 80/100/120 символов не встречалось? А вы думаете что все делают это добросовестно? Я в своем случае привел вам примеры того, что таблицы просто не могут иметь никакой вменяемый общий префикс. Поиск по нему — даст слишком много результатов в любом случае, и опять вернемся к тому же самому — нужно знать где искать.
Сейчас такие БД наверное редкость (я х.з.). Я лично — предпочту LINQ нежели чем динамический SQL в процедуре — но наши БД начали свою историю в 1990-х, а не нарисованы на коленке в 2016-м. Поэтому извините — откровенного говна — я не встречал. Но кое-что приходилось переписывать полность, в том числе и из-за: невменяемое форматирование + невменяемые запросы + они неудовлетворяли исходным требованиям. Встретите ли вы там sp_executesql — или нет — вопрос другого порядка. И второе — да, я работал в проекте где использовались динамические таблицы (другой проект). Поэтому немного остро на это реагирую. Не стоит безаппялиционно призывать к логике — это абсолютно лежит на совести девелоперов. Есть культура и вы в курсе — будет все ок. Нет культуры или вы не совсем в курсе всего — то ок не будет, греп не поможет. Хватит уже хелло ворд натягивать на весь мир. Оно не так, и вы это знаете.
ОК>>Какая фантазия? ТС нафантазировал уже. Поэтому я его и спросил о реальных случаях. Теперь ты мне снова предлагаешь проявить фантазию! И я тебя снова спрошу. Ты в реальном коде встречал такое или фантазируешь опять тут только? F> Я объясню ещё раз: я работал в проекте где чистого SQL было 250MB исходников.
Сколько это в базах, таблицах и хранимых процедурах? Количество.
F>Только люди которые имели опыта 10+ лет там разбирались. Все остальные, в том числе и я — фантазировали себе не весть что. С течением времени — это исправляется. У нас было до поры до времени весьма строгое оформление исходников, тем не менее — приходилось встречаться с уже описанными вещами. Поэтому мои фантазии — местами преувеличены — но осонованы на реальных историях. F> Суть сводится приблизительно к одному: на определенном этапе — реально понимают что-то 2-3 человека, которые заняты и спросить вы у них сможете только на перекурах, и то только если вы курите. Так что как-бы "досвидания".
Мне все это знакомо. И динамический сиквел, и таблицы в которых был год и прочая хрень, но я ни разу не видел чтобы кто-то разбивал идентификатор на несколько частей. Найти можно было все! Даже с динамической состовляющей.
ОК>>А так, нафантазировать и я могу. Радикальный пример я привел выше и повторю его специально для тебя: F> Такого бреда нет наверное нигде. Но это не отменяет бредово отформатированный код, в котором внезапно таблицы с именами склеиваются посередине.
Вот ни разу не видел чтобы идентификатор разбивался посередине! Динамическую составляющую видел, а вот чтобы идентификатор невозможно было найти грепом из-за разбиения оного — ни разу не видел.
F>Что, ограничение в 80/100/120 символов не встречалось? А вы думаете что все делают это добросовестно? Я в своем случае привел вам примеры того, что таблицы просто не могут иметь никакой вменяемый общий префикс. Поиск по нему — даст слишком много результатов в любом случае, и опять вернемся к тому же самому — нужно знать где искать.
Видел ограничения на количество else if-ов у базы в хранимых процедурах. Такие здоровые процедуры были. Парсер просто отказывался понимать большее количество else if-ов хотя синтаксически все было правильно.
F> Сейчас такие БД наверное редкость (я х.з.). Я лично — предпочту LINQ нежели чем динамический SQL в процедуре — но наши БД начали свою историю в 1990-х, а не нарисованы на коленке в 2016-м. Поэтому извините — откровенного говна — я не встречал. Но кое-что приходилось переписывать полность, в том числе и из-за: невменяемое форматирование + невменяемые запросы + они неудовлетворяли исходным требованиям. Встретите ли вы там sp_executesql — или нет — вопрос другого порядка. И второе — да, я работал в проекте где использовались динамические таблицы (другой проект). Поэтому немного остро на это реагирую. Не стоит безаппялиционно призывать к логике — это абсолютно лежит на совести девелоперов. Есть культура и вы в курсе — будет все ок. Нет культуры или вы не совсем в курсе всего — то ок не будет, греп не поможет. Хватит уже хелло ворд натягивать на весь мир. Оно не так, и вы это знаете.
Дружище, хочешь ты этого или нет, но греп это фундаментальный инструмент. Все эти Майкрософтовские покрышки и есть тот самый греп. Ты ставишь в вину грепу если прип помощи него нельзя какой-нибудь идентификатор. На деле-то греп свою работу делает как ни крути. Ставь в вину разработчикам которые разбивают идентификатор на несколько частей (если допустить что такое встречается повсеместно, в чем я лично сомневаюсь).
I>- как хранят вообще код баз данных? (я видел в студии sql server 2008 проект, этим вообще кто-то пользуется?)
в VCS.
I>- как комбинировать код и данные? т.е. если код у меня будет где-то в svn лежать, то как при обновлениях баз загружать или менять данные в них?
Скрипты заливки системных данных (не пользовательских) тоже можно класть в VCS.
Делать патчи в БД, от версии к версии.
I>- как выявлять неиспользуемые артефакты? скрипты какие-то, утилиты может быть?
Ника, кроме как мозгом. Поиском по исходникам. sp_depends (sysdepends), но он может врать.
I>- имеет ли смысл (ну вообще имеет, но имеет ли большой смысл) как-то строго связывать версии приложения и баз данных? и если да, то как.
Да, жёстко и безальтернативно.
Т.е. версия должна быть одна на всё. Всё, весь код -- в одной базе VCS, в одном репозитории. Всё бранчить и мёржить вместе,
версии делать вместе, всех слоёв, сколько бы их ни было.
Попробуй вежливо использовать... 
