- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
/**
* Converts the Accpac fields to names that do not
* require Sherlock Holmes to decipher.
*
* @param arcus Accpac customer object
*/
public Store(final ARCus arcus) {
name = trim(arcus.getIdcust());
description = trim(arcus.getNamecust());
addressLine1 = trim(arcus.getTextstre1());
addressLine2 = trim(arcus.getTextstre2());
addressLine3 = trim(arcus.getTextstre3());
addressLine4 = trim(arcus.getTextstre4());
suburb = trim(arcus.getNamecity());
state = trim(arcus.getCodestte());
postalCode = trim(arcus.getCodepstl());
country = trim(arcus.getCodectry());
contactName = trim(arcus.getNamectac());
phone1 = trim(arcus.getTextphon1());
phone2 = trim(arcus.getTextphon2());
email = trim(arcus.getEmail2());
department = arcus.getAudtorg();
}
anonimb84a2f6fd141 27.05.2013 08:59 # −5
someone 27.05.2013 09:02 # +1
anonimb84a2f6fd141 27.05.2013 16:40 # −5
Map то есть, а замыкания?
bormand 27.05.2013 16:59 # +7
Lure Of Chaos 27.05.2013 10:41 # 0
roman-kashitsyn 27.05.2013 10:44 # +1
Lure Of Chaos 27.05.2013 10:46 # +2
ну тогда и не говно.
vistefan 27.05.2013 15:45 # 0
Всегда ваш, grammar nazi.
DBdev 27.05.2013 17:15 # −1
WTF?
bormand 27.05.2013 17:24 # −2
DBdev 27.05.2013 18:27 # −1
bormand 27.05.2013 18:28 # +2
DBdev 27.05.2013 18:34 # 0
> s/ь/ъ/
данная конструкция является абстрактным синтаксическим анализатором (в котором алгоритм следующий: 1. Берем весь текст 2. Ищем второй аргумент во всем тексте 3. Заменяем найденные значения на третий аргумент) и если grammar nazi использует некую существующую реализацию (vi что-ли линухное?), то мой низший разум не смог постичь сей истины.
defecate-plusplus 27.05.2013 18:38 # 0
sed, но в vi так же, да
bormand 27.05.2013 18:40 # +3
> то мой низший разум не смог постичь сей истины.
Да не парьтесь Вы так ;) Здесь же не собеседование и не экзамен. Все лучше всего знают то, с чем постоянно работают. Я вот, например, в SQL нуб-нубом. Только сегодня узнал про on delete cascade в foreign ключах. А до этого ебашил каскадное удаление ручками, как последний ламер.
DBdev 27.05.2013 18:47 # +2
Я из всего извлекаю для себя плюсы :)
Хотел подЪебловить spell checker'а, а выучил для себя дефолтовое поведение функции замены в линуксовых текстовых процессорах.
bormand 27.05.2013 18:54 # 0
Аналогично ;) Хотя далеко не все, что я узнал на ГК, потом пригодится на практике.
DBdev 27.05.2013 19:21 # +2
Опасная штука, будьте осторожны.
NO ACTION (когда ошибка выскакивает при попытке удалить) - будет побезопаснее. Удалять данные только через интерфейс (ORM, хранимая процедура), который все зависимости отслеживает.
bormand 27.05.2013 19:29 # +1
inkanus-gray 27.05.2013 20:21 # +3
bormand 27.05.2013 20:22 # 0
> платформозависимость
Кул стори, бро.
inkanus-gray 27.05.2013 20:43 # +4
Тем временем шёл 2013-й год, а foreign keys были не во всех движках...
bormand 27.05.2013 21:33 # +2
anonimb84a2f6fd141 27.05.2013 21:52 # 0
guest 27.05.2013 23:57 # −1
bormand 28.05.2013 05:47 # +2
- не дает вставить запись с кривым значением, которого нет в связанной таблице
- удаляет записи, если запись, на которую они ссылались, была удалена (ну или запрещает удалять записи, на которые кто-то ссылается)
- обновляет поле со ссылкой, если оно изменилось в той записи, на которую ссылаются (ну или тупо запрещает его менять)
Как-то так.
anonimb84a2f6fd141 28.05.2013 09:06 # −5
bormand 27.05.2013 21:40 # 0
scriptin 27.05.2013 22:49 # 0
guest 27.05.2013 23:56 # +2
inkanus-gray 28.05.2013 05:12 # +4
Исправил.
anonimb84a2f6fd141 28.05.2013 09:06 # +1
Зато сортировка за O(n^2).
bormand 28.05.2013 05:41 # 0
Ога, за счет table-level блокировок. Только вот часто ли кому-то нужно считать все записи в таблице?
inkanus-gray 28.05.2013 05:43 # 0
Если не сравнивать с другими СУБД, кроме мистера Мускула, то:
1. Индексы FULLTEXT в InnoDB появились только в версии 5.6 и то как костыль. На самом деле FULLTEXT не нужен, потому что внешние индексаторы, например, Sphinx, превосходят его и по функционалу, и по производительности.
2. MERGE работает только с таблицами MyISAM: https://kb.askmonty.org/en/merge/
3. This feature of MyISAM is not available in InnoDB; the value of 'id' will start over at 1 for each different value of 'abc':
4. InnoDB нет на популяных хостингах. Пруфлинк.
http://masterhost.ru/service/hosting/virtual/personal-server/for-one/
bormand 28.05.2013 06:01 # +3
Сомнительная плюшка. На тех же хостингах все равно прав не хватит. Да и сервак стопать ради импорта-экспорта пары табличек... MySQL Way, чо.
У нормальных СУБД один хуй есть тулзы для hot backup'а. А кроме переезда (бекап+рестор) и восстановления бекапа других причин для экспорта-импорта огромных кусков базы в одном и том же формате не вижу.
> InnoDB нет на популяных хостингах.
Вот так вот пыхеры и живут. Сидя жопой на кактусе, и думая, что будет с базой, у которой нет поддержки логирования, если сервак внезапно отрубится.
eth0 28.05.2013 06:25 # +2
У mysql'я есть своя ниша применимости, там не принято думать о надёжности. Но я видел кучу сайтов с тупо лежащей или убитой базой, просто из-за внезапного перезапуска сервера.
roman-kashitsyn 28.05.2013 07:05 # +4
Не уверен, что 99% пыхеров особо думают "а что, если...", просто пишут or die("кан нот коннект"). Думаю, здоровая паранойя (файл не откроется... коннект не удастся... сокет не откроется... база упадёт...) более свойственна людям с системным бэкграундом.
Lure Of Chaos 28.05.2013 08:20 # +1
ага, а ресурс сам освободится (соединение, файл)
bormand 28.05.2013 08:23 # +2
А куда он денется? Это же один из столпов пыхи.
Lure Of Chaos 28.05.2013 08:33 # +4
так я и говорю, что он приучает к плохому. потом эти же люди бросают упаковки и окурки просто на асфальт.
eth0 28.05.2013 17:09 # +1
Причина и следствие попутаны местами, но в остальном ничо так.
Odin 03.11.2018 17:35 # 0
А у ненормальных?
Мистер Хэнки 27.05.2013 20:16 # 0