10 Обычных ошибок SQL

10 Обычных ошибок SQL - манекены

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

Не думайте, что ваши клиенты знают, что им нужно

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

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

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

Не игнорировать область проекта

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

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

Не учитывайте только технические факторы

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

Не избегайте обратной связи с клиентом

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

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

Вы не всегда можете использовать свою любимую среду разработки

Вероятно, вы потратили месяцы или даже годы на освоение конкретной среды СУБД или приложений. Но ваша любимая среда - независимо от того, что она есть - имеет сильные и слабые стороны.

Поэтому вместо того, чтобы объединять то, что на самом деле не лучшее решение, укусите пулю. У вас есть два варианта: либо подняться по кривой обучения более подходящего инструмента, а затем использовать его или откровенно сказать своим клиентам, что их работу лучше всего сделать с помощью инструмента, которым вы не являетесь экспертом по использованию.

Тогда предложите, чтобы клиент нанял кого-то, кто может быть продуктивным с этим инструментом сразу. Профессиональное поведение такого рода гарантирует уважение ваших клиентов. (К сожалению, если вы работаете на компанию, а не на себя, это поведение также может вас уволить или уволить.)

Не используйте исключительно любимую архитектуру системы

Никто не может быть экспертом во всем. Системы управления базами данных, которые работают в среде телеобработки, отличаются от систем, работающих в средах клиент / сервер, совместное использование ресурсов, веб-ресурсов или распределенных баз данных. В любом случае, выберите лучшую архитектуру, даже если это означает переход на работу. Не получить работу лучше, чем получить ее и создать систему, которая не отвечает потребностям клиента.

Не изолировать таблицы базы данных в изоляции

Если вы неправильно идентифицируете объекты данных и их отношения друг с другом, ваши таблицы базы данных могут ввести ошибки в данные и уничтожить достоверность любых результатов. Чтобы создать звуковую базу данных, вы должны рассмотреть общую организацию объектов данных и тщательно определить, как они соотносятся друг с другом. Вы должны определить, что подходит, учитывая текущие и прогнозируемые потребности вашего клиента.

Не пренебрегайте проектными отзывами

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

Не пропускайте бета-тестирование.

Даже если вы будете тестировать его всеми возможными способами, приложение обязательно будет содержать режимы отказа, которые вы не обнаружите. Бета-тестирование означает предоставление приложения людям, которые не знают, как он был разработан.

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

Не забудьте документировать свой процесс

Если вы считаете, что ваше приложение настолько совершенное, что его никогда не нужно рассматривать, еще раз, подумайте еще раз.Единственное, что вы можете быть абсолютно уверены в этом мире, - это изменение. Рассчитывай на это. Через полгода вы не будете помнить, почему вы разработали то, что вы делали, если только вы не тщательно документируете, что вы сделали, и почему вы так поступили.

Задокументируйте свою работу. Поместите более подробно, чем вы считаете разумным. Он окупится позже.