Вообще когда я бралась за этот проект я очень надеялась избавиться от поля FileName в индексе совсем, так как в некоторых запросах используются много полей таблицы и все равно возникает key lookup. К сожалению, при тестах обнаружили, что его отсутствие сказывается на производительности. Добавили в сам индекс исходя из того, что оно все таки кое-где используется в WHERE и оно было раньше в индексе. Возможно, вы правы и нужно было прогнать еще раз вариант с INCLUDE.
Спасибо за замечание, хотя тип действительно NVARCHAR(900), к счастью ни одного файла с таким названием в системе нет, хотя все равно есть предупреждение при создании
Warning! The maximum key length is 900 bytes. The index 'IX_ClientFile_StorageId_FolderId_FileStatus_FileName' has maximum length of 1809 bytes. For some combination of large values, the insert/update operation will fail.
Про комменты что все плохо в старой профессии далеко не каждый хирург в нашей стране (даже хороший) может похвастаться стажировками в США, Франции и Чехии и оттого мне особенно грустно читать эту статью, что из профессии уходят хорошие спецы!
У меня муж тоже хирург и когда я вижу какой объем информации он каждый день поглощает, чтобы совершенствоваться в профессии я вижу, что у меня это детский лепет.
И мне очень грустно, что в нашей стране большинство мед специализаций так низко оплачивают. Это какое абсолютное несоответствие между нагрузкой, требованиям к знаниям и мозгам, пользы, которую человек приносит и тем уровнем компенсации, которую он получает.
Мой муж иногда говорит, что медицину в России уже ничто не спасет, и что с каждым годом будет становиться все хуже и хуже. К сожалению иногда кажется что это правда. И мы будем ходить с красивой улыбкой (стоматология все таки хоть как то оплачивается) и больными сердцами, желудками и прочими частями тела.
Неожиданный вопрос. И хотелось его расширить, но могу пофантазировать.
Я бы перефразировала и разделила на 2 вопроса:
1) надо ли делать отдельный тип в базе или использовать INT (или TINYINT)
2) надо ли делать таблицу справочник или а вот тут не ясно — а расшифровка что значат целые числа где будет?
На первый вопрос — смотрите вы когда делаете свой перечисляемый типа в БД — вы получается автоматически получите качественные данные — то есть в БД будут только те данные которые вы ждете. И если у вас 5 возможных значений — то их и будет 5 и туда не прокрадется какая-нибудь неожиданная штука.
Этот же эффект можно достичь чек constraint ами или внешним ключом.
Если вариант внешний ключ — вы делаете таблицу справочник, и используете внешний ключ. Мне такой способ нравится. Потому что тут у вас и тип стандартный, и вы получаете данные которых ждали, и у вас тут же расшифровка.
Есть минус — если у вас например таких таблиц будет много, ну например 150. Тогда делается одна таблица справочник в дополнении к описанию и значению — добавляете тип. Тут уже с внешними ключами хуже, но зато нет 150 таблиц.
Вы абсолютно правы, иногда у разработчиков замылевается глаз и никто не замечает, что ключ нигде не используется. Тут либо поменять тип — либо что тоже прекрасно — удалить его.
В принципе мне кажется хорошим советом удалить вообще все, что не используется.
Немного встряну в вашу дискуссию.
На мой взгляд тут есть 2 стороны медали.
Обычно уникальность в рамках таблицы (BIGINT) достаточна, если мы не собираемся объединять сущности в одну таблицу — что делается редко, хотя бывает.
Кроме того вспомним, что чем «шире» запись тем дольше будет чтение, а опять же есть вариант не поместиться в стандартный для записи размер в MS SQL сервере.
Про уникальны глобально — наверное это неплохо, если у вас например список сотрудников и ключ guid — и вы покупаете другую компанию и вам надо как то слить данные и у них (ура ура!) тоже есть таблица сотрудников, в которой тоже ключ guid.
В принципе мне кажется, простите за банальность — для каждой задачи свое решение.
К сожалению каждый из нас ограничен своим опытом, поэтому можно друг другу доказывать что одно решение лучше другого, а окажется, что решаемые задачи были разными — и в одном случае лучше решение первого человека, а в другом — второго.
Верно, тут дело в «по умолчанию» — и по умолчанию это (1,1) — и часто этот момент упускается. Кроме того, если по каким то причинам ключ отображается в приложении клиента — отрицательные значения уже не используют.
Спасибо, отличная статья. Вообще поняла, что вообще не надо было писать ничего кроме 3го способа — так как это то, чем я хотела поделиться, первые 2 в реальности не использовала. Хотя опыт с переходом на BigInt описанный вами — через вью и триггер был.
Спасибо за пример! Про замыленный глаз — это точно!
Про это конкретное предложение: получается корявый смысл, ведь я пыталась сказать, если значение ключа используется где-то вне БД, то 114 дней — мало, потому что надо менять и внешние приложения, и саму базу.
Смотря что за проект, если это бывший стартап — там если начинается лавинообразный рост, работы столько, что команда не знает за что хвататься, и это при том, что идет найм, в таком случае это и происходит. Возможно есть еще сценарии, но в нормальном enterprise такого конечно быть не должно.
Согласна, тут в зависимости от срочности — если это таблица из-за которой работа дальше не идет, что нибудь типа информации о продажах и пока не починят, то продавать не могут это одно. А если что-то не очень важное, то совсем другое.
Так как у нас 2017 год, то БД практически всегда должна использовать юникод.
Но для хранение юникод данных используется в 2 раза больше места, чем для хранение в локальной кодировке. Я не делала проекты, которые бы могли быть только локальными — мне кажется это может быть госсектор или что то еще только локальное, может быть областное, и оно не предполагает хранения отображаемых данных. Например. названия улиц — потому что могут решить их продублировать на китайском — и будет проблема.
В общем это я к чему, вроде и 2017й год и дисковое пространство дешевле. Но
Например у нас 100 полей со строковыми данными, для простоты размером до 200 символов каждое. Для MS SQL берем Varchar (1 байт) и Nvarchar (2 байта на символ)
Varchar 2000 байт на строку
NVarchar 4000 байт на строку
Вроде мало — какая разница-то?
А теперь представим что у нас добавляется этих строк много.
То есть когда у вас 4 Тб данных или 8 Тб это все таки имеет значение. Опять же тут надо все таки очень сильно думать — будет у вас больше одного языка и латиницы или нет.
И да в 99% надо использовать юникод.
Тут очень важно вовремя остановится, и видимо мне не удалось толком передать этот момент.
Конечно, именно сделать то, что сейчас актуально наиболее важно для проекта. А то так если пилить задачи на будущее, можно прошляпить настоящее.
Дополню про локализацию — нет сразу поддержку всех языков вводить не нужно, это излишний очень большой кусок работы. А вот тип строк юникод — можно выбрать, это объем работы на начальном этапе никак не изменит. Да, это увеличит объем на диске, но в начале данные не занимают много места. Если точно известно что это не стратап или потенциально (пусть и в самых смелых фантазиях) международное приложение, а например, приложение для госсектора — тут можно и юникод не использовать, так как язык ну уже совсем точно будет один.
Про логи — не надо сразу ставить 2 недели, но какой-то срок поставить надо. А главное настроить процедуру их удаления. Ок, если вы не знаете сколько они могут понадобится — поставьте удалять через 3 месяца, через 1 год, через 3. И настройте сразу процедуру. В процессе работы вы поймете как часто и за какой период эта информация нужна. Если не чистить мусор сразу, то через 3 года об удалении обычно никто не помнит, а через 5 лет у вас будет помойка, которую будет тяжело и долго разгребать. В плохом варианте — помоек будет много.
Спасибо за дополнение, да согласна, ключевая идея — определить срок хранения, даже если это 1 год, 3 года или 5. Если сначала определили какой-то большой срок — например 5 лет иногда возможно посмотреть как часто происходит обращение к этим данным, если к данным старше 1 года никто не обращался ни разу — можно выгрузить эти данные вообще куда-нибудь в файл и оставить на каком-нибудь медленном диске, на случай обращения.
Прямо самая суть! Задача ключа как раз сказать когда мы имеем дело с тем же объектом, а когда это уже другой объект, пусть и с частично совпадающими свойствами. Понятно, что «сферического коня в вакууме» или «идеального ключа» тут не будет, важно выбрать что-то, что будет выполнять задачу идентификации объекта достаточно хорошо, в рамках поставленной задачи. В идеале еще заглянуть в хрустальный шар и посмотреть, как рамки поставленной задачи могут расшириться. Но хрустальные шары иногда мутные, и не всегда видно, как и куда проект пойдет в дальнейшем.
У меня муж тоже хирург и когда я вижу какой объем информации он каждый день поглощает, чтобы совершенствоваться в профессии я вижу, что у меня это детский лепет.
И мне очень грустно, что в нашей стране большинство мед специализаций так низко оплачивают. Это какое абсолютное несоответствие между нагрузкой, требованиям к знаниям и мозгам, пользы, которую человек приносит и тем уровнем компенсации, которую он получает.
Мой муж иногда говорит, что медицину в России уже ничто не спасет, и что с каждым годом будет становиться все хуже и хуже. К сожалению иногда кажется что это правда. И мы будем ходить с красивой улыбкой (стоматология все таки хоть как то оплачивается) и больными сердцами, желудками и прочими частями тела.
Я бы перефразировала и разделила на 2 вопроса:
1) надо ли делать отдельный тип в базе или использовать INT (или TINYINT)
2) надо ли делать таблицу справочник или а вот тут не ясно — а расшифровка что значат целые числа где будет?
На первый вопрос — смотрите вы когда делаете свой перечисляемый типа в БД — вы получается автоматически получите качественные данные — то есть в БД будут только те данные которые вы ждете. И если у вас 5 возможных значений — то их и будет 5 и туда не прокрадется какая-нибудь неожиданная штука.
Этот же эффект можно достичь чек constraint ами или внешним ключом.
Если вариант внешний ключ — вы делаете таблицу справочник, и используете внешний ключ. Мне такой способ нравится. Потому что тут у вас и тип стандартный, и вы получаете данные которых ждали, и у вас тут же расшифровка.
Есть минус — если у вас например таких таблиц будет много, ну например 150. Тогда делается одна таблица справочник в дополнении к описанию и значению — добавляете тип. Тут уже с внешними ключами хуже, но зато нет 150 таблиц.
В принципе мне кажется хорошим советом удалить вообще все, что не используется.
На мой взгляд тут есть 2 стороны медали.
Обычно уникальность в рамках таблицы (BIGINT) достаточна, если мы не собираемся объединять сущности в одну таблицу — что делается редко, хотя бывает.
Кроме того вспомним, что чем «шире» запись тем дольше будет чтение, а опять же есть вариант не поместиться в стандартный для записи размер в MS SQL сервере.
Про уникальны глобально — наверное это неплохо, если у вас например список сотрудников и ключ guid — и вы покупаете другую компанию и вам надо как то слить данные и у них (ура ура!) тоже есть таблица сотрудников, в которой тоже ключ guid.
В принципе мне кажется, простите за банальность — для каждой задачи свое решение.
К сожалению каждый из нас ограничен своим опытом, поэтому можно друг другу доказывать что одно решение лучше другого, а окажется, что решаемые задачи были разными — и в одном случае лучше решение первого человека, а в другом — второго.
Про это конкретное предложение: получается корявый смысл, ведь я пыталась сказать, если значение ключа используется где-то вне БД, то 114 дней — мало, потому что надо менять и внешние приложения, и саму базу.
Но для хранение юникод данных используется в 2 раза больше места, чем для хранение в локальной кодировке. Я не делала проекты, которые бы могли быть только локальными — мне кажется это может быть госсектор или что то еще только локальное, может быть областное, и оно не предполагает хранения отображаемых данных. Например. названия улиц — потому что могут решить их продублировать на китайском — и будет проблема.
В общем это я к чему, вроде и 2017й год и дисковое пространство дешевле. Но
Например у нас 100 полей со строковыми данными, для простоты размером до 200 символов каждое. Для MS SQL берем Varchar (1 байт) и Nvarchar (2 байта на символ)
Varchar 2000 байт на строку
NVarchar 4000 байт на строку
Вроде мало — какая разница-то?
А теперь представим что у нас добавляется этих строк много.
То есть когда у вас 4 Тб данных или 8 Тб это все таки имеет значение. Опять же тут надо все таки очень сильно думать — будет у вас больше одного языка и латиницы или нет.
И да в 99% надо использовать юникод.
Конечно, именно сделать то, что сейчас актуально наиболее важно для проекта. А то так если пилить задачи на будущее, можно прошляпить настоящее.
Дополню про локализацию — нет сразу поддержку всех языков вводить не нужно, это излишний очень большой кусок работы. А вот тип строк юникод — можно выбрать, это объем работы на начальном этапе никак не изменит. Да, это увеличит объем на диске, но в начале данные не занимают много места. Если точно известно что это не стратап или потенциально (пусть и в самых смелых фантазиях) международное приложение, а например, приложение для госсектора — тут можно и юникод не использовать, так как язык ну уже совсем точно будет один.
Про логи — не надо сразу ставить 2 недели, но какой-то срок поставить надо. А главное настроить процедуру их удаления. Ок, если вы не знаете сколько они могут понадобится — поставьте удалять через 3 месяца, через 1 год, через 3. И настройте сразу процедуру. В процессе работы вы поймете как часто и за какой период эта информация нужна. Если не чистить мусор сразу, то через 3 года об удалении обычно никто не помнит, а через 5 лет у вас будет помойка, которую будет тяжело и долго разгребать. В плохом варианте — помоек будет много.