\ یک بار در Last.fm ما یک سرریز عدد صحیح در یک فیلد شناسایی داشتیم. دقیقا یادم نیست کجاست اما من به یاد دارم که ناراحتی ناشی از داشتن یک دسته از مشاغل Hadoop در حالی که ما برای به‌روزرسانی نوع مربوطه عجله داشتیم، مختل شد، نمی‌توانست غرور جمعی را برای داشتن بیش از 2 میلیارد مورد نیاز به این همه شناسه از بین ببرد.
صرفه‌جویی با شناسه‌ها به ندرت ایده خوبی است، اما برای من بدترین سردردهای مربوط به شناسه‌ها از شناسه‌هایی بود که ارزش معنایی داشتند.
\ در Tuenti (که زمانی بزرگترین شبکه اجتماعی در اسپانیا بود) مفهومی مشابه صفحات فیس بوک وجود داشت. صفحات دارای انواع و انواع فرعی بودند. یک نوع صفحه ممکن است «گروهی» باشد که دارای زیرمجموعه‌های «کسب و کار» یا «جامعه» است. نوع دیگر می‌تواند «مکان» با زیرگروه‌هایی مانند «فروشگاه» یا «مکان‌نما» باشد.
\ شناسه‌های صفحه رشته‌هایی بودند که با الحاق شناسه‌های عددی از نوع، نوع فرعی و سپس یک فیلد افزایشی در یک DB تشکیل شده بودند. اگر بازدید کردید https://tuenti.com/p/3_2_6691 شما فورا معنی را می فهمید این یک “مکان” (3) از نوع “فروشگاه” (2) بود، و شناسه فروشگاه 6691 بود. شناسه‌های صفحه که به این روش تجزیه می‌شوند برای اهداف متعدد مفید خواهند بود. انتخاب یک پیاده‌سازی نوع خاص از کنترل‌کننده‌ها برای نوشتن صفحه مربوطه، مسیریابی به یک قطعه پایگاه داده، از این قبیل چیزها.
\ در برخی …
سئو PBN | خبر های جدید سئو و هک و سرور