Оптимальная структура DB для дополнительного полевого объекта
gulp.task('reload', function(done){
browserSync.reload();
done();
});
gulp.task('serve', function(done){
browserSync({
server: 'src'
});
gulp.watch('src/*.html', gulp.series('reload'));
done();
});
Вы можете видеть в приведенном выше коде, что я добавил done() обратные вызовы - они нужны для того, чтобы сигнализировать об асинхронном завершении, чтобы задачи могли быть запущены в секунду и т. Д.
8 ответов
Дизайн, с которым Вы экспериментируете, является изменением Значения атрибута объекта, и это идет с большой проблемами и неэффективностью. Это не хорошее решение для того, что Вы делаете, за исключением последнего средства.
То, что могло быть лучшим решением, - то, что описывает fallen888: составьте таблицу "подтипа" для каждого из Ваших подтипов. Это хорошо, если у Вас есть конечное число подтипов, которое походит на то, что Вы имеете. Затем Ваши определенные для подтипа атрибуты могут иметь типы данных, и также a NOT NULL ограничение при необходимости, которое невозможно, если Вы используете дизайн EAV.
Одна остающаяся слабость дизайна таблицы подтипа - то, что Вы не можете осуществить это, строка существует в таблице подтипа просто, потому что основная строка в таблице суперкласса говорит, что это должно. Но это - более умеренная слабость, чем представленные дизайном EAV.
править: Относительно Вашей дополнительной информации о comments-to-any-entity да это - довольно общий шаблон. Остерегайтесь поврежденного решения, названного "полиморфная ассоциация", которая является техникой, которую многие люди используют в этой ситуации.
Как насчет этого вместо этого... каждый подтип получает свою собственную Таблицу базы данных. И основная/супер таблица просто имеет varchar столбец, который содержит название Таблицы базы данных подтипа. Затем у Вас может быть что-то вроде этого...
Entity
------
ID
Name
Type
SubTypeName (value of this column will be 'Dog')
Dog
---
VetName
VetNumber
etc
Если Вы не хотите, чтобы Ваш (под-) имена таблиц был значениями varchar в базовой таблице, у Вас может также просто быть таблица SubType, первичный ключ которой будет в базовой таблице.
Единственное обходное решение (при сохранении strucure) должно иметь отдельные таблицы:
create table IntProps(...);
create table StringProps(...);
create table CurrencyProps(...);
Но я не думаю, что это - хорошая идея...
Один общий подход имеет таблицу значения ключа, содержат несколько столбцов, один для каждого типа данных, т.е. StringValue, DecimalValue, и т.д.
Просто знайте о торговле queryability и производительностью для схемы базы данных, которую Вы не должны изменять. Вы могли также рассмотреть отображение ORM или объектную базу данных.
Спасибо за ответы. Я объясню немного более конкретно, в чем я нуждаюсь. Существует потребность программировать blog+forum веб-сайт, и я смотрел на структуру DB WordPress.
Существует сильная необходимость в способности поместить комментарии в любой вид 'объекта', как запись в блоге или вложение видеофайла к ней. Так как вышеупомянутая структура DB была очень легка масштабироваться, и выполнить все наши потребности было причиной ее выбора.
Но это не поздно для изменения его, для порождения этого находится на этапе ранней разработки. Также наша модель пахнет теперь как абсолютно основанный на древовидной иерархии DB. На данный момент я приму Bill Karwin и ответы fallen888, но возможно я вхожу в полностью неправильное направление?
Вы могли иметь на ключ/таблицу значений типа. Доступная таблица должна была бы закодировать доступность определенной пары ключа/типа для указания на правильно введенный ключ/таблицу значений.
Это походит на очень неэффективную архитектуру в для находящиеся на строке реляционные базы данных как бы то ни было.
Возможно, необходимо ли смотреть на ориентированную реляционную базу данных столбца?
о пользовательской способности добавить новое поле к таблице:
Я восхищаюсь всеми этими людьми, делающими комментарии.
Я раньше интересовался такого рода вещью несколько лет назад, но недавно написал мало кода (кроме определенных PHP и MySQL).
Я думаю, что хорошо, если Вы хотите продолжать идти - можно закончить с чем-то новым.
Извините, что вылил любую холодную воду на схеме - я восхищаюсь Вашими усилиями. Моя персональная есть уверенность, что, если Вы заходите достаточно далеко в этом направлении, Вы закончите с системой, которая интерпретирует больше естественного языка, чем SQL. (Приблизительно в 1970 SQL было на самом деле записанное Продолжение, и это на самом деле обозначало "структурированный английский язык запросов", но после того, как они стандартизировали его в 1970-х - я думаю, что кто-то сказал, что Oracle была первой коммерческой реализацией, 19079, "англичане" были подвезены, потому что я предполагаю, что они решили, что это было только крошечное подмножество английского языка.
Я выдохся в этой области, потому что у меня нет задания. Без легкого задания, которое оплачивает счета, где я могу экспериментировать с этими идеями, немного трудно сконцентрироваться на этой области.
С наилучшими пожеланиями ко всем.
извините, я записал 19079 выше, я имел в виду 1979 год. Oracle получила их первый контракт, пишущий базу данных для ЦРУ.