Является ли таблица с одним столбцом хорошим дизайном? [закрыто]
Это работает отлично для меня. Он передает ферму и отключает кнопку и через 2 секунды активирует кнопку.
<button id="submit" type="submit" onclick="submitLimit()">Yes</button>
function submitLimit() {
var btn = document.getElementById('submit')
setTimeout(function() {
btn.setAttribute('disabled', 'disabled');
}, 1);
setTimeout(function() {
btn.removeAttribute('disabled');
}, 2000);}
В ECMA6 Syntex
function submitLimit() {
submitBtn = document.getElementById('submit');
setTimeout(() => { submitBtn.setAttribute('disabled', 'disabled') }, 1);
setTimeout(() => { submitBtn.removeAttribute('disabled') }, 4000);}
15 ответов
Да, это, безусловно, хороший дизайн - спроектировать стол таким образом, чтобы он был наиболее эффективным. «Плохой дизайн РСУБД» обычно связан с неэффективностью.
Однако я обнаружил, что в большинстве случаев дизайна с одним столбцом можно было бы выиграть от дополнительного столбца. Например, в кодах состояния обычно может быть указано полное имя штата во втором столбце. Или с черным списком могут быть связаны заметки. Но если вашему проекту действительно не нужна эта информация, то вполне нормально иметь единственный столбец.
Да, это нормально. но поле идентификатора не могло повредить?
Единственный вариант использования, который я могу придумать, - это таблица слов, возможно, для игры в слова. Вы обращаетесь к таблице только для того, чтобы убедиться, что строка является словом: выберите слово из слов, где слово =?. Но есть гораздо лучшие структуры данных для хранения списка слов, чем реляционная база данных.
В противном случае, данные в базе данных обычно помещаются в базу данных, чтобы воспользоваться преимуществами отношений между различными атрибутами данные. Если ваши данные не имеют атрибутов, помимо их значения, как эти отношения будут развиваться?
Итак, хотя это и не является незаконным, в общем случае вам, вероятно, не следует иметь таблицу только с одним столбцом.
Да, если поле является первичным ключом, как вы и сказали. Причина в том, что если вы вставите повторяющиеся данные, эти строки будут доступны только для чтения. Если вы попытаетесь удалить одну из повторяющихся строк. он не будет работать, потому что сервер не будет знать, какую строку удалить.
Назначение базы данных - связать части информации друг с другом. Как вы можете сделать это, когда нет данных, к которым можно было бы относиться?
Возможно, это какая-то таблица компиляции (например, FirstName + LastName + Birthdate), хотя я все еще не уверен, зачем вам это нужно.
РЕДАКТИРОВАТЬ: Я мог видеть использование такой таблицы для простого списка. Это то, для чего вы его используете?
Я бы сказал в целом да. Не уверен, почему вам нужен только один столбец. Из этого правила есть некоторые исключения, которые я видел эффективно. Это зависит от того, чего вы пытаетесь достичь.
Они не совсем удачный дизайн, когда вы думаете о схеме базы данных, но на самом деле их следует использовать только как служебные таблицы.
Я видел числовые таблицы эффективно использовались в прошлом.
Я постоянно использую одностолбцовые таблицы - в зависимости, конечно, от того, использует ли уже проект приложения базу данных. После того, как я выдержал накладные расходы на создание соединения с базой данных, я помещаю все изменяемые данные в таблицы, где это возможно.
Я могу придумать два варианта использования одностолбцовых таблиц OTMH:
1) Элемент данных существует. Часто используется в раскрывающихся списках. Также используется для простых тестов на легитимность.
Например. двухбуквенные аббревиатуры штатов США; Почтовые индексы, на которые мы отправляем; слова законные в Scrabble; и т. д.
2) Разреженный двоичный атрибут, т. е. в большой таблице, двоичный атрибут, который будет истинным только для очень небольшого числа записей. Вместо добавления нового логического столбца я мог бы создать отдельную таблицу, содержащую ключи записей, для которых атрибут истинен.
Например. сотрудники, у которых неизлечимая болезнь; банки с 360-дневным годом (большинство используют 365); и др.
-Al.
В основном я видел это в таблицах типов поиска, таких как таблица состояний, которую вы описали. Однако, если вы это сделаете, обязательно установите столбец в качестве первичного ключа для обеспечения уникальности. Если вы не можете установить это значение как уникальное, вам не следует использовать один столбец.
В редких случаях таблица с одним столбцом имеет смысл. Я создал одну базу данных, в которой список допустимых языковых кодов представлял собой таблицу с одним столбцом, используемую в качестве внешнего ключа. Не было никакого смысла иметь другой ключ, поскольку ключ был сам по себе. И не было фиксированного описания, так как описания языковых кодов могут различаться в зависимости от языка для некоторых контекстов.
В общем, любой случай, когда вам нужен авторитетный список значений, не имеющих каких-либо дополнительных атрибутов, является хорошим кандидатом для одноразового использования. столбец таблицы.
Один случай, который я иногда обнаруживал, выглядит примерно так:
Таблица country_id , содержит только один столбец с числовым идентификатором для каждого country.
Таблица Country_description , содержит столбец с идентификатором страны, столбец с идентификатором языка и столбец с локализованным названием страны.
Таблица company_factories , содержит информацию для расположен каждый завод компании, в том числе страна в Вич.
Если это действительно необходимо, то я не вижу проблемы. Может быть, вам просто нужен список возможностей для отображения по какой-то причине, и вы хотите иметь возможность динамически изменять его, но вам не нужно связывать его с другой таблицей.
Я использовал их раньше. Один мой клиент хотел автоматически заблокировать любого, кто пытается зарегистрироваться по номеру телефона из этого большого списка, так что это был всего лишь один большой черный список.
В терминах реляционной алгебры это было бы унарное отношение, означающее « эта вещь существует »
Да, нормально иметь таблица, определяющая такое отношение: например, для определения домена.
Значения такой таблицы, конечно же, должны быть естественными первичными ключами.
Таблица поиска простых чисел - вот что приходит к мои мысли в первую очередь.
Все мои таблицы имеют по крайней мере четыре технических поля, серийный первичный ключ, временные метки создания и модификации и логическое значение мягкого удаления. В любом черном списке вы также захотите узнать, кто добавил запись. Поэтому для меня ответ - нет, таблица только с одним столбцом не имеет смысла, кроме как при создании прототипа.