Ну в данном конкретном случае я с Вами совершенно согласен. И заведение другой базы только усложняет работу. Особливо если данные действительно однотипные. Это ж значит что и сопутствующие таблицы/процедуры/функции/вью — всё надо в двух базах хранить. Или вообще в третьей…
Но меня обуял вопрос по поводу этой Вашей фразы:
Конечно, нормализация нужна, а уж если производительность не является очень узким местом — то нормализация просто необходима (Хотя в противном случае я бы посоветовал серверов БД купить побольше, а не базу портить).
Не хотите ли Вы этим сказать, что нормализация — всегда ухудшает производительность?
Ну, судя по всему, Вы согласны с тем, что нормализация нужна? Важно, чтоб её результатом было повышение эффективности, а не просто «разделение данных, потому что так в книжках пишуть». Я правильно Вас понима?
А что? Некоторые СУБД поддерживают guid'ы нативно. И умеют автоматически генерить их. И Hibernate, например, умеет генерить guid'ы для полей БД. Иногда это бывает оправданно. Хотя да, использовать это налево и направо чревато.
Ну речь идёт не только о гуидах? Работал, помнится, с чётырёхгигабайтной базой, где все ключи были строковые. Фильмы, актёры, режиссёры — все ключи были в виде DVD334534, STAR887744, DIR897778. 50 тыщ фильмов, 200-300 тыщ актёров и базюка с удовольствием начинала пыхтеть и пыжиться.
Ну, справедливости ради надо заметить, что кроме строковых ключей там были и другие бомбы запроектированы «дизайнерами», но и ключи тоже свою роль играли. И немалую.
Совершенно с Вами согласен — вопрос лишь в том, чьё время в данный момент выгоднее экономить — программиста или сервера. При большой нагрузке порой выгоднее
* иметь ненормализованные таблицы, чтобы избежать лишних джойнов;
* использовать директ вызовы запросов к базе данных;
* выполнять или кучу запросов в одной транзакции, чтобы сэкономить время на создание/закрытие коннекций;
* или наоборот разделять одну транзакцию на части, потому что иначе процесс коммита/роллбака займёт нереально много ресурсов
… да мало ли ещё каких извращений в жизни бывает.
НО! Всё хорошо в меру. И если время, которое требуется на поддержку «неудобного» кода будет слишком велико, может быть выгоднее прикупить мозгов железяке, сэкономив время кодеров, которое тоже не слишком дёшево.
Конечно, это имеет смысл тогда, когда выигрыш во времени разработки действительно ощутим. И если приложение «одноразовое» — один раз создано и больше его никто трогать не будет — то, возможно, заморачиваться с красотой кода смысла нет. Но кто гарантирует, что через месяц/полтора не потребуется что-то дорабатывать? Об удобстве этого достаточно подробно высказался konsoletyper чуть ниже.
В Вашем случае красота действительно эфемерна. Но вообще представьте, что у вас есть объект «животинка». И от него унаследованы и лошадка и собачка и овечка и слоник. И движение right у каждого из них — своё собственное. Слоник и собачка в очень даже разные щёлочки пролезают. Овечку вообще за забор не пускают. А уж если добавим, например, совушку, так там вообще четвёртый разговор.
А в случае с ООП стукнулся сервер к объекту «животинка» — а тот уж пусть сам разбирается, кто он, что он и куда и как двинется.
А если таких лошадок — писят штук? И каждая в своём месте сидит? К объектам в таком случае обращаться ой как удобно.
ЗЫ: да что я Вам рассказываю сказки про инкапсуляцию, наследование, полиморфизм — Вы ж и так наверняка всё знаете. Важно, чтоб ООП для пользы дела было, а не просто для ООП-ния.
Ну бывает и вообще великолепный вариант, когда в базе хранится XML. Порой просто огромного размера, чтоб его и поредактировать стандартными средствами работы с базой данных было б никак. Пусть последующие разработчики сделают какие-нить специальные инструменты, чтоб какую-нить мелкую фитюлинку поменять.
А вообще по поводу баз данных добавил бы ещё пунктиков
N. Храните всю разметку в базе данных — база ж для данных предназначена! Значит все таблицы, фонты, цвета и размеры должны быть там!
N+1. Гораздо удобнее все данные хранить в одной таблице. Ну и что, что из 300 полей в каждой записи будут задействованы только 10-20?! Зато всегда понятно, в какой таблице данные надо искать.
N+2. Для каждого селекта, инсерта и апдейта надо делать отдельную процедуру. Когда число процедур в базе перерастает три сотни, начинаешь по особому чувствовать свою значимость!
N+3. Никогда при вставке значений в таблицу не перечисляй поля! Никогда! Только значения! И если какой-то лопух попытается потом таблицу изменить, пусть ка найдёт все твои процедуры, которые в эту таблицу что-то писали, а теперь падают из-за несоответствия типов или несовпадения количества параметров! Пусть почувствует всю глубину своего падения. А то наставят порой дефолтных значений, думают, что их это защитит…
Я всего лишь обсуждаю именно тот вариант «интровертов», которых описывал mr_gorbunov. Терминология, соответственно, не моя :)
Так вот люди, которые от вопросов «такого толка» впадают в ступор, далеко не в каждой команде смогут работать эффективно. Я, например, когда выбирал работников, на это обращал особое внимание, ибо микроклимат в коллективе разрушить легко, а наладить обратно — сложнее.
Мммм… да что вы говорите?! А откуда такая информация, что экстравертам в рабочем коллективе нужны интроверты?
Сколько раз сталкивался с интровертами, всегда как-то получалось, что они предпочитают работать «соло». То есть чтоб их никто и ни по какому поводу не трогал. Тогда только и могут выдавать результат. А если человек при любом неосторожном вопросе может впасть в ступор… Брррр… А представьте, что вся команда состоит из таких. И всё рабочее время хотя бы 20% коллектива пребывает в ступоре. Ибо то заказчик забежит, то манагер, то ещё какой дизастер.
Но многие мои знакомые интроверты и вопросами такого толка можно вогнать их в полный ступор и даже причинить некие моральные, не побоюсь этого слова, страдания подобным допросом.
А нужны ли такие люди в коллективе? Не забывайте, что «хорошесть» специалиста зависит и от его совместимости с командой.
Тут, имхо, надо принимать во внимание, в каком режиме придётся людям работать. Весьма вероятно, что задачи будут возникать «вдруг» и решать их придётся именно быстро-быстро и в максимально стрессовом режиме.
Для таких случаев нужны люди не просто грамотные, но и стрессоустойчивые.
Что, впрочем, совсем не отменяет остальных минусов описанного метода «проверки»
Просто маппет-шоу… Приделал Express Checkout. Там можно указать Shipping Address. А вот Billing Address — нельзя.
Ну и ещё получается, что Express Checkout нельзя выполнять без регистрации. В случае же с Payment Standard пользователю достаточно ввести информацию о кредитке — регистрация не нужна.
Да, если не найдётся других путей, придётся идти туда. Эту доку я читал, проблема лишь в том, что тут придётся несколько раз обращаться к серверу — сначала с данными, потом с полученным токеном.
Ага, понимаю Ваше замечание. Однако, судя по документации, address_override используется в том случае, если оплату производит зарегистрированный пользователь. В этом случае адрес, отправленый с сайта, будет использован вместо адреса, который записан у пользователя в профиле.
Но речь в любом случае идёт о Billing Address. Меня интересует Shipping Address. Он выставляется равным Billing Address в любом случае, независимо от значения переменной address_override.
Ну и для незарегистрированного пользователя поведение системы от этой переменной тоже никак не зависит :(
1. Я хочу, чтобы оплата проводилась на сайте PayPal, а не на нашем.
2. Я знаю, что мы можем получить информацию с пейпола. Мне нужно иметь возможность передать пейполу информацию о шиппинг адресе, которая имеется у нас на сайте.
www.google.ru/search?q=Dean+Eagle
Но меня обуял вопрос по поводу этой Вашей фразы:
Не хотите ли Вы этим сказать, что нормализация — всегда ухудшает производительность?
Ну речь идёт не только о гуидах? Работал, помнится, с чётырёхгигабайтной базой, где все ключи были строковые. Фильмы, актёры, режиссёры — все ключи были в виде DVD334534, STAR887744, DIR897778. 50 тыщ фильмов, 200-300 тыщ актёров и базюка с удовольствием начинала пыхтеть и пыжиться.
Ну, справедливости ради надо заметить, что кроме строковых ключей там были и другие бомбы запроектированы «дизайнерами», но и ключи тоже свою роль играли. И немалую.
* иметь ненормализованные таблицы, чтобы избежать лишних джойнов;
* использовать директ вызовы запросов к базе данных;
* выполнять или кучу запросов в одной транзакции, чтобы сэкономить время на создание/закрытие коннекций;
* или наоборот разделять одну транзакцию на части, потому что иначе процесс коммита/роллбака займёт нереально много ресурсов
… да мало ли ещё каких извращений в жизни бывает.
НО! Всё хорошо в меру. И если время, которое требуется на поддержку «неудобного» кода будет слишком велико, может быть выгоднее прикупить мозгов железяке, сэкономив время кодеров, которое тоже не слишком дёшево.
Конечно, это имеет смысл тогда, когда выигрыш во времени разработки действительно ощутим. И если приложение «одноразовое» — один раз создано и больше его никто трогать не будет — то, возможно, заморачиваться с красотой кода смысла нет. Но кто гарантирует, что через месяц/полтора не потребуется что-то дорабатывать? Об удобстве этого достаточно подробно высказался konsoletyper чуть ниже.
N+4. все данные должны храниться в разных таблицах и связываться длинными строковыми ключами. Так же красивее :)
Естественно, везде нужен здравый смысл. Но нормализацию базы проводить всё же надо, имхо :)
А в случае с ООП стукнулся сервер к объекту «животинка» — а тот уж пусть сам разбирается, кто он, что он и куда и как двинется.
А если таких лошадок — писят штук? И каждая в своём месте сидит? К объектам в таком случае обращаться ой как удобно.
ЗЫ: да что я Вам рассказываю сказки про инкапсуляцию, наследование, полиморфизм — Вы ж и так наверняка всё знаете. Важно, чтоб ООП для пользы дела было, а не просто для ООП-ния.
А вообще по поводу баз данных добавил бы ещё пунктиков
N. Храните всю разметку в базе данных — база ж для данных предназначена! Значит все таблицы, фонты, цвета и размеры должны быть там!
N+1. Гораздо удобнее все данные хранить в одной таблице. Ну и что, что из 300 полей в каждой записи будут задействованы только 10-20?! Зато всегда понятно, в какой таблице данные надо искать.
N+2. Для каждого селекта, инсерта и апдейта надо делать отдельную процедуру. Когда число процедур в базе перерастает три сотни, начинаешь по особому чувствовать свою значимость!
N+3. Никогда при вставке значений в таблицу не перечисляй поля! Никогда! Только значения! И если какой-то лопух попытается потом таблицу изменить, пусть ка найдёт все твои процедуры, которые в эту таблицу что-то писали, а теперь падают из-за несоответствия типов или несовпадения количества параметров! Пусть почувствует всю глубину своего падения. А то наставят порой дефолтных значений, думают, что их это защитит…
Так вот люди, которые от вопросов «такого толка» впадают в ступор, далеко не в каждой команде смогут работать эффективно. Я, например, когда выбирал работников, на это обращал особое внимание, ибо микроклимат в коллективе разрушить легко, а наладить обратно — сложнее.
Сколько раз сталкивался с интровертами, всегда как-то получалось, что они предпочитают работать «соло». То есть чтоб их никто и ни по какому поводу не трогал. Тогда только и могут выдавать результат. А если человек при любом неосторожном вопросе может впасть в ступор… Брррр… А представьте, что вся команда состоит из таких. И всё рабочее время хотя бы 20% коллектива пребывает в ступоре. Ибо то заказчик забежит, то манагер, то ещё какой дизастер.
Ну, нафик!
А нужны ли такие люди в коллективе? Не забывайте, что «хорошесть» специалиста зависит и от его совместимости с командой.
«Девелопмент — игра командная!»
Для таких случаев нужны люди не просто грамотные, но и стрессоустойчивые.
Что, впрочем, совсем не отменяет остальных минусов описанного метода «проверки»
Ну и ещё получается, что Express Checkout нельзя выполнять без регистрации. В случае же с Payment Standard пользователю достаточно ввести информацию о кредитке — регистрация не нужна.
Снова что-то не то получается :(
address_overrideиспользуется в том случае, если оплату производит зарегистрированный пользователь. В этом случае адрес, отправленый с сайта, будет использован вместо адреса, который записан у пользователя в профиле.Но речь в любом случае идёт о Billing Address. Меня интересует Shipping Address. Он выставляется равным Billing Address в любом случае, независимо от значения переменной
address_override.Ну и для незарегистрированного пользователя поведение системы от этой переменной тоже никак не зависит :(
1. Я хочу, чтобы оплата проводилась на сайте PayPal, а не на нашем.
2. Я знаю, что мы можем получить информацию с пейпола. Мне нужно иметь возможность передать пейполу информацию о шиппинг адресе, которая имеется у нас на сайте.