| ← Май 2007 → | ||||||
|
1
|
2
|
3
|
4
|
6
|
||
|---|---|---|---|---|---|---|
|
7
|
8
|
9
|
10
|
11
|
13
|
|
|
14
|
15
|
16
|
17
|
19
|
20
|
|
|
21
|
22
|
23
|
24
|
25
|
27
|
|
|
28
|
29
|
30
|
31
|
|||
За последние 60 дней ни разу не выходила
Сайт рассылки:
http://www.sql-ex.ru
Открыта:
15-09-2004
Статистика
0 за неделю
Новости сайта "Упражнения по SQL" (http://www.sql-ex.ru) 138
Новости сайта "Упражнения по SQL (http://www.sql-ex.ru)" Выпуск 138 (5 мая 2007 г.)
Новости сайта§ Лидеры решали пропущенные задачи: § Продвинулись в рейтинге: § На этой неделе сертифицированы: § Число подписчиков - 3556 Число участников рейтинга - 10134 Число участников второго этапа - 951 Сертифицировано на сайте - 154 Лучшие результаты (ТОР 20)
Лучшие результаты за неделю
Изучаем SQLДесять характерных ошибок в проектировании базы данныхLouis Davidson (оригинал: Ten Common Database Design Mistakes )Перевод Моисеенко С.И. Никакой список ошибок не будет исчерпывающим. Люди (включая и меня самого) допускают время от времени множество действительно глупых вещей, пытаясь что-то сделать. Данный список просто отражает ошибки в проектировании базы данных, с которыми я недавно столкнулся или с которыми я постоянно сталкиваюсь. Замечание:Я уже дважды поднимал эту тему. Если Вы хотите послушать подкаст-версию, посетите блестящий сайт Грэга Лоу SQL Down Under . Я также представил урезанную десятиминутную версию в PASS для Simple-Talk. Первоначально их было десять, потом шесть, а сейчас опять десять. Но эти десять не те же самые десять ошибок, которые были первоначально; они отражают мое сегодняшнее понимание. Прежде, чем я начну этот список, позвольте мне немного пооткровенничать. Я обычно имею проповедника, который прежде проповедовал сам себе столько, что был допущен к конгрегации. Когда я говорю или пишу статью, я должен прислушиваться к его тихому голосу в моей голове, который помогает отфильтровывать мои собственные плохие привычки, дабы удостовериться, что я преподаю только лучшие методы. Хотелось бы надеяться, что после чтения этой статьи, тихий голос в вашей голове будет сообщать Вам, когда Вы начинаете отклоняться от того, что является правильным в смысле методов проектирования базы данных. Итак, список:
Плохой проект/планирование"Если Вы не знаете, куда идете, то любая дорога приведет вас туда" - Джордж Харрисон Пророческие слова для всех областей жизни и описание проблемы, которой зачумлены многие современные проекты. Позвольте мне спросить: Вы наняли бы подрядчика для строительства дома, чтобы потребовать от него заливать фундамент на следующий же день? Или что хуже, Вы потребовали бы, чтобы это было сделано без плана или проекта дома? Хочется надеяться, что Вы ответили "Нет" на оба вопроса. Проект необходим как гарантия, что дом, который Вы хотите, будет построен, и что земля, на которой Вы строите его, не провалится в какую-нибудь подземную пещеру. Если Вы ответили "Да", я не уверен, поможет ли Вам то, что я собираюсь рассказать. Как и дом, хорошая база данных строится с предусмотрительностью, с надлежащей заботой и вниманием, которое уделяют характеру данных, которые будут находиться в ней. Это не может быть пущено на самотек. Поскольку база данных - краеугольный камень почти каждого бизнес проекта, то если Вы не найдете время, чтобы определить требования к проекту и то, как база данных будет им удовлетворять, тогда, вероятно, весь проект пойдет не так и станет неуправляем. Кроме того, если Вы не сделаете правильный проект базы данных в самом начале, то тогда Вы столкнетесь с тем, что любые существенные изменения в структуре базы данных, которые потребуется сделать, будут оказывать огромное воздействие на весь проект, что значительно увеличит вероятность увеличения сроков его выполнения. Слишком часто надлежащая фаза планирования игнорируется в пользу "получения сделанного". Когда по какому-либо направлению проект встречает преграду, и неизбежно возникают проблемы из-за нехватки надлежащего проектирования и планирования, то нет "никакого времени", чтобы вернуться, дабы исправить ситуацию должным образом, используя надлежащие методы. Поскольку когда начинается "рубка", благие обещания возвратиться и исправить кое-что позже, выполняются, на самом деле, очень редко. По общему признанию, невозможно предсказать каждую потребность, которую ваш проект должен будет выполнить, и предвидеть каждую проблему, с которой, вероятно, придется столкнуться, однако важно ослабить воздействие потенциальных проблем в максимально возможной степени посредством тщательного планирования. Игнорирование нормализацииНормализация представляет собой ряд методов, разбивающих таблицы на составные части до тех пор, пока каждая таблица не будет представлять собой одну и только одну "вещь", а ее столбцы полностью описывать только одну "вещь", которую эта таблица представляет. Концепция нормализации в течение около 30 лет является основанием, на которое опирается SQL и реляционные базы данных. Другими словами, SQL был создан для работы с нормализованными структурами данных. Нормализация - это не только некий заговор программистов баз данных против прикладных программистов (что является просто побочным эффектом!) SQL весьма аддитивен по своей природе; это проявляется в том, что если Вы имеете биты и элементы данных, то легко создать множество значений или результатов. В предложении FROM Вы берете набор данных (таблицу) и добавляете (JOIN) его к другой таблице. Вы можете собрать вместе столько наборов данных, сколько вам угодно, чтобы произвести необходимое вам окончательное множество. Эта аддитивная природа чрезвычайно важна не только для простоты разработки, но также и для производительности. Индексы являются наиболее эффективными, когда они могут работать со всем ключевым значением. Всякий раз, когда Вам нужно использовать SUBSTRING, CHARINDEX, LIKE и так далее, чтобы вытащить значение, которое объединено с другими значениями в едином столбце (например, чтобы вычленить фамилию человека из столбца, содержащего полное имя), парадигма SQL начинает ломаться, и данные становятся всё менее доступными для поиска. Итак, нормализация ваших данных существенна для хорошей производительности и простоты разработки, но остался вопрос: "Какой нормализации достаточно?" Если Вы читали какие-нибудь книги по нормализации, то Вы слышали много раз, что существенной является 3-я Нормальная Форма, но действительно полезны и 4-ые и 5-ые Нормальные Формы и, как только Вы сталкиваетесь с ними, не жалейте времени, требуемого на нормализацию. Однако в действительности часто оказывается, что не всегда даже первая Нормальная Форма создается правильно. Всякий раз, когда я вижу таблицу с повторяющимися именами столбцов, которые отличаются лишь добавлением числа, я прихожу в ужас. И я ужасаюсь довольно часто. Рассмотрим следующий пример таблицы Customer (Клиент): 
Всегда ли имеется 12 платежей (Payment)? Существенен ли порядок платежей? Имеет ли NULL-значение смысл НЕИЗВЕСТНО (пока еще не заполнен), или это означает пропущенную оплату? И когда оплата была сделана?!? Оплата не является характеристикой Клиента и не должна храниться в таблице Customer. Детали платежей должны храниться в таблице Payment, в которую Вы можете также записывать дополнительную информацию об оплате, например, когда оплата была сделана и за что: 
В этом втором проекте каждый столбец хранит единственную единицу информации о единственной "вещи" (оплата), и каждая строка представляет конкретный случай оплаты. Этот второй проект потребует немного большего количества кода на ранних стадиях процесса, но более вероятно, что Вы будете в состоянии выяснить то, что происходит в системе без необходимости выслеживать программиста, который делал эту часть проекта, чтобы пнуть его в торец … простите … узнать, что он имел в виду. (продолжение следует...) Полезная информация§ Все статьи, публикуемые в рассылке, затем выкладываются на сайте Книги и статьи по SQL. § В продаже еще имеется книга SQL. Задачи и решения, посвященная анализу ошибок, допускаемых при решении задач первого этапа. На сайте издательства Питер можно сделать заказ и познакомиться с содержанием. § Желающих поспособствовать популяризации сайта прошу проголосовать/поставить закладку в социальных сетях: КонтактыПо всем вопросам, связанным с функционированием сайта, проблемами при решении упражнений, идеями вы можете обращаться к Сергею И.Моисеенко msi77@yandex.ru. Вы также можете предложить свои задачи для публикации на сайте. |
| В избранное | ||
