Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Хорошие вещи терять нельзя особенно БД  [new]
alex_od
Member

Откуда: Южная Пальмира
Сообщений: 1559
Когдато Уважаемый superbluesman выложил хорошую базу, я по ней многому научился, и вот она доступна для скачивания, не смотря на то что про нее три года никто не вспоминал!!! А Жаль!!!

http://www.lepsik.com/db/classifier.rar

Качать всем, потому что она создана по всем правилам SQL, весит 11 метров.

Сообщение было отредактировано: 21 янв 07, 12:29
20 янв 07, 00:14    [3669798]     Ответить | Цитировать Сообщить модератору
 Re: Хорошие вещи терять нельзя особенно БД, Качать ВСЕМ  [new]
alex_od
Member

Откуда: Южная Пальмира
Сообщений: 1559
вот текст вьюшки v_country:

SELECT b.id_area, b.sequence_, b.name_area, b.phone, c.codestrana, 
c.code2strana, c.code3strana, c.barcode, c.code, c.code_old, 
c.flagReference
FROM dbo.PS_TypeArea a INNER JOIN
dbo.PS_Area b ON a.id_typearea = b.id_typearea INNER JOIN
dbo.PS_About_Country c ON b.id_area = c.id_area
WHERE (a.scname = 'страна')
20 янв 07, 00:27    [3669813]     Ответить | Цитировать Сообщить модератору
 Re: Хорошие вещи терять нельзя особенно БД, Качать ВСЕМ  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
alex_od
вот текст вьюшки v_country:
И что тут "особенного"?
В приведенном примере (базу качать/восстанавливать неохота, но раз уж приведен этот кусок, стоит предположить, что по нему нам предполагается оценить всю "мощь" базы) используется "не самый удачный" способ именования столбцов - обычно части, составляющие идентификатор или разделяются подчеркиванием - code_strana, CODE_STRANA
или начинаются с большой буквы: codeStrana, CodeStrana и т.д.

Потом - если уж используются латинские/английские наименования (phone, sequence), то это должно распространяться на все поля - чтобы понять смысл названия поля codestrana, нужно после того, как прочитал тот же phone и переключился на "английский":
1) Понять, что тебе "подсунули нечто, отсутствующее в языке, который использовался для именования предыдущего поля - буквосочетание code есть в английском, а вот "strana" - нет.

2) догадаться, что название поля состоит из 2-х слов РАЗНЫХ языков - "Код" в тарнслитерации будет "cod" или даже "kod", но никак не "code"

3) Догадаться, по правилам какого языка строится сочетание этих слов - "Code Country" означает непонятно что вообще, но возможно, что некую страну, из которой "Code" получен - при таком порядке слов в английском "главное" - второе. Возможно, это ссылка или скорее - название (отсутствует префикс id_, используемый для других ключевых полей) страны, к которой относится некий аттрибут/понятие/объект "code".

Если же сочетание сделано по правилам русского языка - то тогда понятно, что поле содержит код страны, но неясно с какого перепуга "автор" запутал читающего, начав название с АНГЛИЙСКОГО "code"

Потом - что такое code3strana? Допустим, что по предыдущему контексту это тоже некий код страны. Но что за код? то ли код 3-ей страны, то ли 3-ий код ЭТОЙ же страны.
"По русски" это "звучит, как "Код 3-ей страны", но по контексту - видимо все-таки некий "Третий код страны".

Еще - если уж выбран способ выделения вьюх припомощи использования префикса v_, то логично ожидать, что у таблиц будет префикс типа t_, по крайней мере - префикс будет в нижнем регистре и означать вид объекса (таблица). А тут какой-то PS_ - верхний регистр и означает "догадайся мол сама", но скорее всего - "содержание" объекта, а не его тип.
Я не большой сторонник использования префиксов, но раз уж они есть - нужна последовательность в их применении.

В названиях таблиц - опять смесь английского с нижегородским - где-то подчеркивание разделяет части названия, где-то нет. Судя по смыслу, PS_TypeArea все-таки правильно было бы назвать PS_AreaType - заодно при сортировке по имени все таблицы, относящиеся к "Area", находились бы рядом, а так - поди, догадайся, как именно мог автор с таким знанием английского назвать таблицу, описывающую типы "территорий": PS_TipArea? PS_VidArea, PS_ClassArea?

Ну, а PS_About_Country.... :) Тут уже, как говорицца, no comments. :) Для перевода сочетания "Описания стран" автору было явно лениво лезть в словарь, потому, что About - это наречие, которые вообще не подходят для составлении названий таблиц на английском.Хотя автор, знающий, что About означает некое описание, мог бы догадаться использовать хотя бы "Info"... :)

Потом - форматирование....
Брр... Ну есть любители писать JOIN на строке, предыдущей той, в которой упоминается сама таблица. Хм... Мне лично это не по душе - я и так понимаю, что ВСЕ, используемые в запросе таблицы будут соединяться, но мне интересно, как именно данная таблица будет подключена к предыдущей. А для этого, увидев имя таблицы мне нужно: перевести взгляд на строку выше, найти глазами конец строки и посмотреть, что там стоит - некий JOIN или запятая... Не очень-то это и удобно, да и связи лучше бы описывать в одной и той же позиции. Например, так:
FROM        dbo.PS_TypeArea a 
INNER JOIN  dbo.PS_Area b 
    ON a.id_typearea = b.id_typearea 
INNER JOIN  dbo.PS_About_Country c 
    ON b.id_area = c.id_area
WHERE (a.scname = 'страна')
или даже так:
FROM        dbo.PS_TypeArea      a 
INNER JOIN  dbo.PS_Area          b ON a.id_typearea = b.id_typearea 
INNER JOIN  dbo.PS_About_Country c ON b.id_area = c.id_area
WHERE (a.scname = 'страна')
таблицы с одной позиции, алиасы тоже все четко видны ну и связи не перемешаны с остальным. Да и сами алиасы таблиц лучше использовать "смысловые" - ta для PS_TypeArea, "a" для PS_Area, "ac" для PS_About_Country.

Не знаю, кто как, но я предпочитаю при поиске начинать условие с поля той таблицы, в которой ищем, то есть не a.id_typearea = b.id_typearea, а b.id_typearea = a.id_typearea , но возможно, это мои личные "тараканы". :)

Потом, если уж это "шедевр", то зачем скобки в условии? ;)

ЗЫ Если обидел - имейте в виду, не хотел. Просто не стоит так "очаровываться" вещами. Можно нарваться на не самые лучшие творения, а когда еще и другого не знаешь..... :(
В общем вердикт такой - если бы это написал только что научившийся - это нормально. Хотя в любом нормальном учебнике по программированию все-таки описан хоть какой-нибудь принцип именования объектов и правило, что выбранного принципа нужно строго придерживаться. Но вот уситься по такому проекту я бы не рекомендовал... :(
20 янв 07, 02:06    [3669873]     Ответить | Цитировать Сообщить модератору
 Re: Хорошие вещи терять нельзя особенно БД, Качать ВСЕМ  [new]
alex_od
Member

Откуда: Южная Пальмира
Сообщений: 1559
Но все же, с чем сравнивать: с правилами или с человеческим фактором;
я предпочитаю и теорию, и чужие базы данных (чтоб убедится, проверить, сравнить);

Покрайней мере автор выложил базу на обсуждение еще три года назад!

https://www.sql.ru/forum/actualthread.aspx?bid=1&tid=145807#1181715
20 янв 07, 02:55    [3669892]     Ответить | Цитировать Сообщить модератору
 Re: Хорошие вещи терять нельзя особенно БД, Качать ВСЕМ  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
alex_od
Но все же, с чем сравнивать: с правилами или с человеческим фактором;
я предпочитаю и теорию, и чужие базы данных (чтоб убедится, проверить, сравнить);

Покрайней мере автор выложил базу на обсуждение еще три года назад!
Но судя по Вашему первому посту, ВСЕ просто обязаны посмотреть на этот образец качественной БД.

Я бы предложил далеко за примерами не ходить - в любой версии 2000 веше MSDE есть прекрасные образцы - NorthWind и pubs.
20 янв 07, 03:34    [3669902]     Ответить | Цитировать Сообщить модератору
 Re: Хорошие вещи терять нельзя особенно БД, Качать ВСЕМ  [new]
alex_od
Member

Откуда: Южная Пальмира
Сообщений: 1559
DeColo®es
alex_od
Но все же, с чем сравнивать: с правилами или с человеческим фактором;
я предпочитаю и теорию, и чужие базы данных (чтоб убедится, проверить, сравнить);

Покрайней мере автор выложил базу на обсуждение еще три года назад!
Но судя по Вашему первому посту, ВСЕ просто обязаны посмотреть на этот образец качественной БД.

Я бы предложил далеко за примерами не ходить - в любой версии 2000 веше MSDE есть прекрасные образцы - NorthWind и pubs.


Каждому свое, как говорится, но кроме того криво написана она или нет, все равно есть масса полезных вещей (сами данные стран и городов)- независимо от того нравится вам или нет.

Если у Вас базы не кривые тогда опубликуйте их для обсуждения, и мы тогда всем форумом будем искать там вшей и блох :-)
20 янв 07, 13:21    [3670193]     Ответить | Цитировать Сообщить модератору
 Re: Хорошие вещи терять нельзя особенно БД, Качать ВСЕМ  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
alex_od
Если у Вас базы не кривые тогда опубликуйте их для обсуждения, и мы тогда всем форумом будем искать там вшей и блох :-)
Кто сказал, что они некривые? :)
Я и сам бы их покритиковал, но просто знаю, ПОЧЕМУ там что-то "не так".
А выставлять на обсуждение нужно только ради критики, а не чтобы хвастаться - любой человек в любом проекте найдет, что можно исправить/улучшить/упростить.
Просто опять же - то, что Вы привели совсем необязательно качать ВСЕМ. И не уверен, что стоит учиться по такому "проекту" - несоблюдаются элементарнейшие правила "хорошего тона". :(
20 янв 07, 14:37    [3670334]     Ответить | Цитировать Сообщить модератору
 Re: Хорошие вещи терять нельзя особенно БД, Качать ВСЕМ  [new]
alex_od
Member

Откуда: Южная Пальмира
Сообщений: 1559
автор
Просто опять же - то, что Вы привели совсем необязательно качать ВСЕМ


Допустим не надо было писать (Надо попросить модератора, убрать качать ВСЕМ)

автор
Но у меня вопрос!!! Кто нибудь из этой базы подчерпнул для себя и своих проектов что то ПОЛЕЗНОЕ.
20 янв 07, 15:04    [3670375]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: Хорошие вещи терять нельзя особенно БД  [new]
Alex_496
Member [заблокирован]

Откуда: https://www.dvbi.ru
Сообщений: 3869
те справочники я генерировал в условиях цейтнота, поэтому было не до красивостей кода и наименований.

Сейчас готовлю новые версии, с бОльшим количеством атрибутов, и видимо они уже будут платные занедорого :)
15 авг 11, 17:07    [11121785]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить