Понимаете, вы можете работать с ИНН двумя способами.
Первый способ называется "не заморачиваться". Это значит, что вы не пытаетесь как-либо интерпретировать строку ИНН. Раз вы не пытаетесь её интерпретировать, то вам и хранить её надо целиком и как есть. Если хранить её целиком и как есть - это именно строка, а не номер, т.к. ведущий ноль нужно сохранять. Если вы будете использовать числовой тип данных без особой осторожности, вы рано или поздно этот ноль потеряете (при распечатке документов например).
Второй способы называется" заморочиться и распарсить ИНН". Тогда уж вообще стоит разбить ИНН на составляющие и хранить их в отдельных полях, а контрольные цифры не хранить вообще, т.к. они по сути избыточны. Но тогда вам придётся разбирать/собирать ИНН при работе с БД. Нужно это вам или нет - зависит от задачи. Возможно, налоговая у себя так и делает, чтобы построить индексы для быстрого поиска по отдельным регионам и отделениям, и собирает ИНН на лету при отображении пользователю.
Эти способы альтернативны друг другу. Не стоит их бездумно совмещать. Вы поняли разницу между ними?
Arris ваш ответ я прочёл полностью, включая решение с decimal. Не вижу в нём особого смысла по ряду причин.
> Как ЛИЧНО МНЕ кажется, искать (даже с индексом) по числовому полю лучше, чем по строковому.
Тут такой момент, что строковое поле ПОСТОЯННОЙ длины не так уж медленнее при индексации и LIKE 'AAA%s' поиске. Хотя, дать конкретные советы и рекомендации лучше на конкретной СУБД.
Что значит - БД под каждого разработчика? Совершенно непонятна структура вашего проекта, и почему с каждым разработчиком вы теряете по 6Гб. У вас тестовые данные на продовом сервере?
И если вы едва знакомы с базой, почему вы этим занимаетесь-то? Очевидно, нужно понять, что это за system_logs. Как вы собираетесь куда-то её вынести и сделать её общей (не знаю правда, что вы под этим подразумеваете), если вам неивзестно, что там хранится?
> Пишу программу для перевода jpg файла в массив.
Вы понимаете, что большинство читающих остановятся после этого предложения и перейдут на другой вопрос?
Как вам можно помочь, если вы так описываете вашу задачу?
Etmac например, в ответе Дмитрия - id в отношении Seat я еще могу понять - не всегда хочется тянуть в другие таблицы сложный ключ из 3-х полей, но вот поле id в отношении Reservation - это явно перебор.
Etmac в ReservedSeat первичный ключ - event_id, sector, row, number. Следовательно, вы сможете создать для каждого события столько записей, сколько у вас есть мест на стадионе. Например, будет запись ReservedSeat(10, 'A', 6, 12, 999) - эта запись значит, что в событии с кодом 10 (ваш футбольный матч), место 12 в 6-м ряду в секторе 'A' занято клиентом 999. Также может быть запись ReservedSeat(10, 'B', 7, 3, 888) - она говорит нам, что на том же самом футбольном матче клиентом 888 занято 3-е место в 7-м ряду в секторе 'B'. Так как в первичный ключ входят все поля за исключением user_id, нет никаких причин, по которым под событие может быть только одна запись.
Вам знакомо понятие составного первичного ключа? Если нет, вам необходимо ознакомиться с этим материалом, т.к. тащить id везде куда ни попадя (когда в этом нет явной необходимости) - это ошибка проектирования.
Free_ze нуу.... если брать версии дотнета, где еще был client profile, то я не сказал бы что полный FW это JDK, а клиентский - это JRE. В клиентском, например, есть компилятор. Собственно это меня и смущает, т.к. в JRE компилятора вроде никогда не было)
@VVlados
1) первую версию языка и первый транслятор языка ("Си с классами" транслировался в обычный Си);
2) первую версию стандарта языка;
3) участвует в разработке стандарта языка до сих пор.
Владимир если вы хотите контроллировать в коде (вместо использования транзакций) параллельное изменение данных из нескольких параллельных сессий с БД, то тогда вам придётся отказаться от многопользовательского функционала СУБД и пользоваться ей в стиле SQLite. И весь многопользовательский доступ реализовать уже внутри самого приложения. Ну или другой варинт - работать только с помощью блокировок, как это делали файловые БД типа FoxPro. Вы уверены, что хотите предложить автору вопроса вернуться назад в 90-е? :) Или это сугубо теоретическое замечание?
Я вот тоже не пойму, о чем вы вообще спрашиваете. Вы хотите, чтобы форма не фризилась (неважно каким способом), или вы хотите конкретно решить проблему с потоком? Если второе, то в чём конкретно проблема?
Eugene Leshchinskiy можно, но не полную. Современные поставки сред .NET как правило не содержат инструментов для разработки. Тот же MSBuild раньше был частью .NET Framework, но потом перестал (и правильно). Сейчас .NET Framework это скорее JRE.
Андрей АНАНАС
> То есть, программа заходит в эту строку: "lbl.setText("DLL NOT FOUND!");"
Раз так, значит fct == nullptr, т.е. функция не нашлась) Вот об этой ошибке я и спрашивал.
Моё личное мнение: видеокурс довольно низкого качества, я бы за такое не платил, а купил бы книгу.
5:20 "Когда мы создаём экземпляры... Сначала мы создаём объект... А потом у нас создаются экземпляры." - из этой фразы я ничего не понял, мне кажется читающий тоже не понял, что сказал. Неудивительно, что он мог наговорить про приведение поля к другому типу.
BadCats к сожалению у меня нет подписки и доступа к этому курсу. Говорить, что в данном случае тип ПОЛЯ будет приводится из Circle в Shape я считаю грубым искажением фактов. О таком приведении еще можно поговорить в контексте СВОЙСТВА Figure, и то с оговоркой, что реальный тип свойства в классе ни на какой не изменяется, а мы просто "смотрим" на свойство Figure типа Circle, как на свойство типа Shape (а мы имеем право, т.к. Circle наследуется от Shape).
Либо автор плохо выразился, либо вы его не поняли, либо у этих курсов проблема с теоретической базой. Не понимаю, как опытный .net разработчик может утверждать, что в указанном вам случае делается приведение типа поля.
Понимаете, вы можете работать с ИНН двумя способами.
Первый способ называется "не заморачиваться". Это значит, что вы не пытаетесь как-либо интерпретировать строку ИНН. Раз вы не пытаетесь её интерпретировать, то вам и хранить её надо целиком и как есть. Если хранить её целиком и как есть - это именно строка, а не номер, т.к. ведущий ноль нужно сохранять. Если вы будете использовать числовой тип данных без особой осторожности, вы рано или поздно этот ноль потеряете (при распечатке документов например).
Второй способы называется" заморочиться и распарсить ИНН". Тогда уж вообще стоит разбить ИНН на составляющие и хранить их в отдельных полях, а контрольные цифры не хранить вообще, т.к. они по сути избыточны. Но тогда вам придётся разбирать/собирать ИНН при работе с БД. Нужно это вам или нет - зависит от задачи. Возможно, налоговая у себя так и делает, чтобы построить индексы для быстрого поиска по отдельным регионам и отделениям, и собирает ИНН на лету при отображении пользователю.
Эти способы альтернативны друг другу. Не стоит их бездумно совмещать. Вы поняли разницу между ними?