В чем разница между varchar и nvarchar?
1- Первый способ - определить интерфейс
public interface OnMessage{
void sendMessage(int fragmentId, String message);
}
public interface OnReceive{
void onReceive(String message);
}
2- В вашей деятельности реализовать интерфейс OnMessage
public class MyActivity implements OnMessage {
...
@Override
public void sendMessage(int fragmentId, String message){
Fragment fragment = getSupportFragmentManager().findFragmentById(fragmentId);
((OnReceive) fragment).sendMessage();
}
}
3- В вашем фрагменте реализован интерфейс OnReceive
public class MyFragment implements OnReceive{
...
@Override
public void onReceive(String message){
myTextView.setText("Received message:" + message);
}
}
Это шаблонная версия обработки сообщения, проходящего между фрагментами.
Другим способом передачи данных между фрагментами является использование шины события.
1 - Регистрация / отмена регистрации на шине событий
@Override
public void onStart() {
super.onStart();
EventBus.getDefault().register(this);
}
@Override
public void onStop() {
EventBus.getDefault().unregister(this);
super.onStop();
}
2- Определение класса событий
public class Message{
public final String message;
public Message(String message){
this.message = message;
}
}
3- Поместить это событие в любом месте вашего приложения
EventBus.getDefault().post(new Message("hello world"));
4- Подпишитесь на это событие, чтобы получить его в своем фрагменте
@Subscribe(threadMode = ThreadMode.MAIN)
public void onMessage(Message event){
mytextview.setText(event.message);
}
Дополнительные сведения о , примеры использования и пример проекта о шаблоне шины событий.
7 ответов
nvarchar столбец может хранить любые данные Unicode. varchar столбец ограничивается 8-разрядной кодовой страницей. Некоторые люди думают, что varchar должен использоваться, потому что это занимает меньше места. Я полагаю, что это не корректный ответ. Несовместимости кодовой страницы являются болью, и Unicode является средством исправления для проблем кодовой страницы. С дешевым диском и памятью в наше время, нет действительно никакой причины напрасно тратить время, слоняясь без дела с кодовыми страницами больше.
Все современные операционные системы и платформы разработки используют Unicode внутренне. При помощи nvarchar, а не varchar, можно постараться не делать преобразования кодирования каждый раз, когда Вы читаете из или пишете в базу данных. Преобразования занимают время и подвержены ошибкам. И восстановление после ошибок преобразования является нетривиальной проблемой.
, Если Вы взаимодействуете через интерфейс с приложением, которое использует только ASCII, я все еще рекомендовал бы использовать Unicode в базе данных. ОС и алгоритмы сопоставления базы данных будут работать лучше с Unicode. Unicode избегает проблем преобразования при взаимодействии через интерфейс с другой системы. И Вы будете готовиться к будущему. И можно всегда проверять те данные, ограничивается 7-разрядным ASCII для любой унаследованной системы, которую необходимо обслужить, даже при пользовании некоторыми преимуществами полного устройства хранения данных Unicode.
nVarchar поможет Вам сохранить символы Unicode. Это - способ пойти, если Вы хотите хранить локализованные данные.
Вы правы. nvarchar хранит данные Unicode, в то время как varchar хранит данные однобайтового символа. Кроме различий в устройстве хранения данных (nvarchar требует дважды пространства памяти как varchar), который Вы уже упомянули, главная причина для предпочтения nvarchar [более чем 115] будут интернационализацией (т.е. хранящие строки на других языках).
nvarchar хранит данные как Unicode, таким образом, если Вы собираетесь хранить многоязычные данные (больше чем один язык) в столбце данных, Вам нужен вариант N.
Я всегда использую nvarchar, поскольку он позволяет то, что я создаю для противостояния в значительной степени любым данным, которые я бросаю в него. Моя система CMS делает китайский язык случайно, потому что я использовал nvarchar. В эти дни любые новые приложения не должны действительно касаться суммы требуемого пространства.
varchar: переменная длина, данные символа не-Unicode. Сопоставление базы данных определяет, какую кодовую страницу данные хранятся с помощью.
nvarchar: данные символа Unicode переменной длины. Зависящий от сопоставления базы данных для сравнений.
Вооруженный с этим знанием, используйте, какой бы ни каждый соответствует Вашим входным данным (ASCII против Unicode).
Я бы сказал, это зависит.
Если вы разрабатываете настольное приложение, где работает OS работает в Unicode (например, все текущие системы Windows) и языка, который является встроенным в сопоставление Unicode (строки по умолчанию - это Unicode, как в Java или C #), затем перейдите на Nvarchar.
Если вы разрабатываете веб-приложение, где строки входят в UTF-8, а язык является PHP, который до сих пор не поддерживает Unicode Rateric (в версиях 5.x), то Varchar, вероятно, будет лучшим выбором.