Почему позиционные запросы плохо?
Любой метод, объявленный как статический в Java, принадлежит самому классу. Снова к статическому методу определенного класса можно получить доступ, только обратившись к классу, подобному Class_name.method_name();
. Таким образом, нет необходимости создавать экземпляр класса перед доступом к статическому методу.
Таким образом, метод main () объявлен как static, поэтому к нему можно получить доступ без создания объекта этого класса.
Так как мы сохраняем программу с именем класса, в котором присутствует основной метод (или откуда программа должна начать свое выполнение, применимо для классов без метода main() () (Расширенный уровень)). Таким образом, вышеупомянутым способом:
Class_name.method_name();
основной метод может быть доступен.
Вкратце, когда программа компилируется, она ищет метод main(), имеющий String аргументов, таких как: main(String args[]) в упомянутом классе (то есть по имени программы), и так как в начале он имеет нет возможности создать экземпляр этого класса, поэтому метод main () объявлен как статический.
8 ответов
Первый запрос почти всегда прерывается при изменении схемы таблицы. Второй запрос учитывает любое изменение схемы, которое оставляет его столбцы нетронутыми, и не добавляет столбцы без значений по умолчанию.
Люди, которые выполняют SELECT * запросы, а затем полагаются на позиционную нотацию для извлечения значений, которые их беспокоят. являются суперзлодеями по обслуживанию программного обеспечения по той же причине.
Хотя порядок столбцов определен в схеме, его обычно не следует рассматривать как важный, поскольку он не концептуально важен.
Кроме того, это означает, что любой, кто читает первую версию, должен обратиться к схеме, чтобы узнать, что означают значения. По общему признанию, это похоже на использование позиционных аргументов в большинстве языков программирования, но почему-то SQL в этом отношении немного отличается - мне, конечно, гораздо легче понять вторую версию (при условии, что имена столбцов разумны).
Меня не волнуют теоретические концепции в этом отношении (как и на практике, таблица действительно имеет определенный порядок столбцов). Основная причина, по которой я предпочел бы второй первому, - это добавленный уровень абстракции . Вы можете изменять столбцы в таблице, не запутывая запросы.
Вы должны попытаться сделать ваши SQL-запросы как можно меньше зависимыми от точного макета таблицы.
Первый запрос полагается на таблицу, имеющую только три поля и именно в этом порядке. Любое изменение таблицы приведет к поломке запроса.
Второй запрос полагается только на наличие этих трех полей в таблице, а порядок полей не имеет значения. Вы можете изменить порядок полей в таблице, не нарушая запроса, и вы даже можете добавлять поля, если они допускают нулевые значения или имеют значение по умолчанию.
Хотя вы не очень часто меняете макет таблицы, добавляя добавление дополнительных полей в таблицу - обычное дело.
Кроме того, второй запрос более читабельный. Из самого запроса вы можете сказать, что означают значения, введенные в запись.
Что еще не упоминалось, так это то, что вы часто будете иметь суррогатный ключ в качестве вашего ПК с auto_increment (или что-то подобное) для присвоения значения. В первом случае вам нужно будет указать что-то , но какое значение вы можете указать, если оно не будет использоваться? NULL может быть вариантом, но это не совсем подходит, учитывая, что PK будет установлен на NOT NULL .
Но кроме этого, все "заблокировано для конкретная схема "является гораздо более важной причиной, ИМО.
SQL дает вам синтаксис для указания имени столбца для операторов INSERT и SELECT. Вы должны использовать это, потому что:
- Ваши запросы устойчивы к изменениям в порядке столбцов, поэтому обслуживание требует меньше усилий.
- Порядок столбцов лучше соответствует тому, как думают люди, поэтому он более удобочитаемый. Более ясно думать о столбце как о столбце «Имя», а не о втором столбце.
Я предпочитаю использовать синтаксис, подобный UPDATE:
INSERT t SET one = 1 , two = 2 , three = 3
Который намного легче читать и поддерживать, чем оба примера.
В долгосрочной перспективе, если вы добавите еще один столбец в свою таблицу, ваш INSERT не будет работать, если вы явно не укажете список столбцов. Если кто-то изменит порядок столбцов, ваш INSERT может автоматически вставить значения в неправильные столбцы.