Сколько полей 'слишком многие' в таблице?
Когда вы объявляете ссылочную переменную (т. е. объект), вы действительно создаете указатель на объект. Рассмотрим следующий код, в котором вы объявляете переменную примитивного типа int:
int x;
x = 10;
В этом примере переменная x является int, и Java инициализирует ее для 0. Когда вы назначаете его 10 во второй строке, ваше значение 10 записывается в ячейку памяти, на которую указывает x.
Но когда вы пытаетесь объявить ссылочный тип, произойдет что-то другое. Возьмите следующий код:
Integer num;
num = new Integer(10);
Первая строка объявляет переменную с именем num, но она не содержит примитивного значения. Вместо этого он содержит указатель (потому что тип Integer является ссылочным типом). Поскольку вы еще не указали, что указать на Java, он устанавливает значение null, что означает «Я ничего не указываю».
Во второй строке ключевое слово new используется для создания экземпляра (или создания ) объекту типа Integer и переменной указателя num присваивается этот объект. Теперь вы можете ссылаться на объект, используя оператор разыменования . (точка).
Exception, о котором вы просили, возникает, когда вы объявляете переменную, но не создавали объект. Если вы попытаетесь разыменовать num. Перед созданием объекта вы получите NullPointerException. В самых тривиальных случаях компилятор поймает проблему и сообщит вам, что «num не может быть инициализирован», но иногда вы пишете код, который непосредственно не создает объект.
Например, вы можете имеют следующий метод:
public void doSomething(SomeObject obj) {
//do something to obj
}
В этом случае вы не создаете объект obj, скорее предполагая, что он был создан до вызова метода doSomething. К сожалению, этот метод можно вызвать следующим образом:
doSomething(null);
В этом случае obj имеет значение null. Если метод предназначен для того, чтобы что-то сделать для переданного объекта, целесообразно бросить NullPointerException, потому что это ошибка программиста, и программисту понадобится эта информация для целей отладки.
Альтернативно, там могут быть случаи, когда цель метода заключается не только в том, чтобы работать с переданным в объекте, и поэтому нулевой параметр может быть приемлемым. В этом случае вам нужно будет проверить нулевой параметр и вести себя по-другому. Вы также должны объяснить это в документации. Например, doSomething может быть записано как:
/**
* @param obj An optional foo for ____. May be null, in which case
* the result will be ____.
*/
public void doSomething(SomeObject obj) {
if(obj != null) {
//do something
} else {
//do something else
}
}
Наконец, Как определить исключение & amp; причина использования Трассировки стека
12 ответов
Таблицы базы данных могут законно иметь 30 или больше полей в них. То, на что необходимо посмотреть, является нормализацией данных и имеет ли та нормализация какой-либо смысл. Это будет обычно изменяться в будущем, также. Но, Вы хотите попытаться минимизировать это.
, Например, если у Вас есть таблица, которая имеет адреса в нем, Вы включаете город, состояние и поля почтового индекса в той таблице? Или, Вы только включаете одно поле, которое "указывает" на запись в отдельной таблице для тех значений? Отдельная таблица содержала бы уникальный город, состояние, комбинации почтового индекса. Эффект разделения данных в две таблицы является сокращением объема хранивших данных (скорее всего, но не абсолютный), но немного добавленной сложности, когда Вы переходите к выполнению запросов против базы данных. Теперь, необходимо иметь дело с 2 таблицами вместо всего один. Но с другой стороны это намного более чисто, и намного меньше (вероятно).
реальный ответ, он должен хорошо оставить данные городского государственного почтового индекса в таблице адресов при правильных обстоятельствах. Или, Вы могли бы хотеть "нормализовать" его. Оба хорошо.
Находят хорошего администратора базы данных и нанимают их короткий срок для рассмотрения плана, если это находится в бюджете. Это окупится в конечном счете.
Самый очевидный знак таблица требует нормализации, которую я видел, является полями, заканчивающимися целыми числами: CouponCode1, CouponCode2, CouponCode3.. Вы понимаете. Будут исключения из правила как всегда все же.
Тридцать полей не слишком многие - просто необходимо удостовериться, что данные правильно нормализованы (для которого существует много руководств по сети).
На основе Вашего редактирования, где Вы указываете, что много столбцов будут полями типа опции, которые могут быть добавлены или удаляться со временем, я предположил бы, что следующее является лучшей идеей.
BaseTable:
Id
NonOptionFields
OptionTable:
Id
OptionName
OptionValue
Затем можно связать все опции с базовой записью. Это будет означать, что Вы не должны будете добавлять и удалять столбцы к таблицам все время ly нормализованный способ достигнуть того, что Вы хотите.
Конечно, стандартный ответ , он зависит . Таблица, с которой много полей могли на самом деле иметь довольно большой смысл в некоторых ситуациях.
Думают о данных, которые Вы будете хранить там. Это, вероятно, что многие из этих полей будут ПУСТЫМИ? Что является вероятностью, что эти поля изменяются (например: больше добавляется)?
, Если только определенные поля относятся к определенным объектам, возможно, думайте о помещении тех полей в другую таблицу. С другой стороны, сохраните просто основные, общие поля в одной таблице и дополнительную информацию в другой таблице, одной строке на поле. Как я предложил для другой вопрос (который мог бы быть полезен Вам) :
refs (id, title, refType) -- title of the reference, and what type of reference it is fieldDef (id, fieldName, refType, dataType) -- name of the field, which reference types it applies to, and -- what type of data is stored in these fields (ISDN number, date, etc) fields (refId, fieldId, value) -- where you actually add data to the references.
Примечание, что это было downvoted, и вероятно с серьезным основанием. Это опция , не обязательно наилучший вариант, но это - все еще осуществимый метод. Самый высокий проголосовавший ответ в вопросе, с которым я связался, мог бы быть лучшим решением как бы то ни было.
<час>Редактирование: так как Вы говорите, что это будет содержать вещи как настройки в расчете на пользователя (например: цвет виджета), я на самом деле рекомендовал бы метод, обрисованный в общих чертах выше (с этими тремя таблицами). Возможности состоят в том, что большинство людей оставит вещи в значении по умолчанию, таким образом, у Вас будет стопка бесполезной информации сохраненной. Прочитайте мой ответ в другом вопросе, потому что другие читатели указали на недостатки этого метода.
нет никакого произвольного предела; достаточно сделать задание - хорошее эмпирическое правило
, если Вы имеете лучший дизайн дб, предлагаете это
, если Вы хотите более подробную обратную связь, отправляете схему
Термин "слишком много" является относительным... Вы не должны разделять таблицу только ради сокращения количества полей, особенно если в каждом запросе Вы оказываетесь перед необходимостью присоединяться к ним назад вместе, потому что они - чрезвычайно непосредственные отношения. Если бы поля могут быть разломаны на отдельный, логический объект затем, он имел бы смысл. Например, вместо того, чтобы хранить поля адреса на клиентской таблице, они могли быть перемещены в отдельную таблицу адресов. Это - сырой пример, но он иллюстрирует мой тезис.
Количество полей обычно является не проблемой, но Вы хотите удостовериться, что Ваша база данных правильно noralized. Третья нормальная форма является хорошим началом.
Если необходимо спросить, "Там слишком много полей в этой таблице?" Затем, вероятно, существуют.
Руководство партизана по нормализации по умолчанию:
- таблица А должна иметь первичный ключ и самое большее еще один столбец.
- правило номер 1 Повреждения только так же часто как требуется.
Нет никакого ограничения на количество полей в теории баз данных. Таблица может быть ограничена первичным ключом (даже если этот первичный ключ сделан из 2 полей), означая, что ответ Apocalisp не является очень четким. В противоположном таблица может быть сделана из thousends полей, целых , правила нормальной формы уважают.
, Когда группы полей очевидно недогружены в таблице, может быть умно разделить эту группу полей в другой таблице с отношением 0-1 между основной таблицей и "sub" таблицей.
Из соображений безопасности, это также часто предлагалось (давным-давно: я думаю, что это была моя первая книга реляционных баз данных, сначала опубликованных в 197?) для разделения конфиденциального infos в другой таблице с тем же отношением 0-1 между основным и заменой. Было затем возможно легко ограничить пользовательский доступ к "sub" таблице. Такой конфигурацией можно теперь легко управлять посредством представлений.
Контрольный знак, что Вы сказали. У него есть поля, которые должны в теории быть разделенными в другую таблицу. Другая дешевая распродажа является присутствием многих дополнительных полей.
я сказал бы, что курс в проектировании баз данных является для Вашего DB "Экспертом". И я предложил бы, чтобы Вы повторили на нем, также... это может только помочь Вам вырасти в Вашей карьере :)
OLTP
Исходя из моего опыта проектирования баз данных, в нормализованной базе данных OLTP очень мало таблиц, содержащих безумно большое количество столбцов.
IMO 30 столбцов - это слишком много.
Для меня , не более 10% моих таблиц OLTP имеют большое количество (> 10) столбцов.
OLAP
Теперь, если вы '