Изучение плюсов и минусов
blockquote>В пользу одинарных кавычек
- Меньше визуального беспорядка.
- Создание HTML : HTML-атрибуты обычно разделяются двойными кавычками.
Однако одинарные кавычки столь же легальны в HTML.elem.innerHTML = '<a href="' + url + '">Hello</a>';
elem.innerHTML = "<a href='" + url + "'>Hello</a>";
Кроме того, встроенный HTML обычно является анти-шаблоном. Предпочитают шаблоны.
- Генерация JSON: в JSON разрешены только двойные кавычки.
myJson = '{ "hello world": true }';
Опять же, вам не нужно создавать JSON таким образом. JSON.stringify () достаточно часто. Если нет, используйте шаблоны.
В пользу двойных кавычек
- Парные пары легче обнаружить, если у вас нет цветового кодирования. Как и в случае с консольным журналом или какой-либо установкой источника просмотра.
- Сходство с другими языками: в программировании оболочки (Bash и т. Д.) Существуют строковые литералы с одной кавычкой, но escape-коды не интерпретируются внутри них. C и Java используют двойные кавычки для строк и одинарные кавычки для символов.
- Если вы хотите, чтобы код был действительным JSON, вам нужно использовать двойные кавычки.
В пользу как
В JavaScript нет разницы между ними. Поэтому вы можете использовать то, что сейчас удобно. Например, следующие строковые литералы производят одну и ту же строку:
"He said: \"Let's go!\"" 'He said: "Let\'s go!"' "He said: \"Let\'s go!\"" 'He said: \"Let\'s go!\"'
Одиночные кавычки для внутренних строк и двойные для внешних. Это позволяет вам отличать внутренние константы от строк, которые должны отображаться пользователю (или записываться на диск и т. Д.). Очевидно, что вам следует избегать размещения последнего в вашем коде, но это не всегда можно сделать.
Я запустил сервер MySQL в Docker, как это, просто используя значения по умолчанию:
docker run -d --rm --name mysql -e MYSQL_ALLOW_EMPTY_PASSWORD=true mysql
И создал базу данных следующим образом:
docker exec -it mysql mysql -e 'create database if not exists test'
И затем подключите интерактивный сеанс так:
docker exec -it mysql mysql test
Затем я заполнил его 32 миллионами случайных дат, запустив эту ...
INSERT into dates select date(from_unixtime(rand()*unix_timestamp(now())) );
, а затем выполняя это несколько десятков раз:
INSERT into dates select date(from_unixtime(rand()*unix_timestamp(now())) ) from dates;
Теперь у меня почти в два раза больше дат, чем у вас:
mysql> explain select * from dates;
+----+-------------+-------+------------+------+---------------+------+---------+------+----------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+------+----------+----------+-------+
| 1 | SIMPLE | dates | NULL | ALL | NULL | NULL | NULL | NULL | 33497947 | 100.00 | NULL |
+----+-------------+-------+------------+------+---------------+------+---------+------+----------+----------+-------+
1 row in set, 1 warning (0.00 sec)
Наконец, я могу продемонстрировать, как быстро я могу искать по таблице:
mysql> select count(*), d from dates where d between '2001-01-01' and '2001-12-31' group by d order by d desc;
....
365 rows in set (4 min 31.17 sec)
Имеет смысл, в 2001 году было несколько тысяч результатов на каждый день. (Помните, что эти даты случайным образом распределяются между 1970 - эпохой - и сейчас).
Нет индексов или чего-то еще, и нет настройки SQL. Прошло 4,5 минуты. Надеемся, что это даст вам основание для ожидания вашего сервера и производительности запросов.